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METKCH) FOR SEOJRELY US^6 DIQJTM* SICWATURES 
IN A COWraCIAli CRYPTOGRAPHIC SYSTHf 



aACKSRon tm qf the thvemtiom 
This invention relates to digital signatures. 
More particularly, this invention relates to the use of 
digital signatures and certificates for digital 
5 signatures in a coaaoercial cryptograj^ic system for 
enforcing security policies and authorizatiMt 
requirements in a manner that reduces risks to the 
users. 

Public-key cryptography is a iMdem computer 

10 security technology that can support the creation of 
peerless electronic doctznent systems, providing that 
the user's digital signature on an electronic document, 
that is, the user's electronic authentication and 
verification of the electronic document, can be given 

15 sufficient practical and legal meaning. Such paperless 
electronic document systems, or "dociaient 
architectures," will encoaqfiass not only trading 
partners operating under standard bilateral contracts 
but also global multilateral systems in which any . 

20 entity can, in theory, correspond with any other entity 
in a'legally provable manner, assuming that proper 
seetirity controls are observed throughout. 

Ttiese systems will have enormous commercial 
significance because, in many cases, cost reductions on 

25 the order of 10-to-l can be realized over current paper 
transaction procedures. This improvement is 
sufficiently dramatic such that many organizations 
would, for economic and competitive reasons, be 
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compelled to use them once their practicality had been 
demonstrated • 

No one disputes that paper is a bothersome 
anachronism in the electronic world or that verifying 
5 pen-and-ink signatures is costly and error-prone. At 

least with paper, however, the signer retains the basic 
''contextual controls** of document preparation and 
physical delivery* On a digitally signed electronic 
document, on the other hand, a signer controls only the 

10 encoded signature. All time, place and manner controls 

are absent, and nothing distinguishes a valid user 
signature from one fraudulently produced by another 
user who somehow obtained the first user's smart card 
and PIN* It would not take too many multi-million or 

15 multi-billion dollar losses to erase all the savings 
produced by this **newf angled" office-automation 
technology. Therefore, digital signatures will see 
early use only in consumer "electronic coin purse** 
applications, where exposure is low, and in wholesale 

20 financial transfers, as to which extremely tight 

security procediires are already the norm. However, 
these uses will have little general commercial impact. 

Thus far, major corporations and banks have 
declined to invest in these technologies due to lack of 

25 well-defined risk models and auditing standards and due 
to uncertainties regarding legal and liability issues. 
Serious investments to commercialize digital signatures 
will occur only after leading national auditing and 
legal experts have ruled that these systems contain 

30 adequate security controls to warrant reliance in 
mainstream intra- and inter-corporate business 
transactions, typically in the $10,000 to $10 million 
range* In order for this goal to be achieved, security 
controls must be formulated to reduce the risks of 
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participants in digital signature document systems to 
the absolute lovest level technically achievable. 

There are two types of cryptographic systems in 
vhich digital signatures have been used: symmetric and 
5 asymmetric cryptographic syst«fts. PK^IRES 1(a) and 
1(b) illustrate the use of syma^tric and asymiMtric 
algorithms for encryjption. In symmetric (conventional) 
cryptography, as shown in FI6URS 1(a), the eender and 
recipient of a ccutmunication share a secret key 11. 

10 This key is used by the sender, the originator of a 
cramunication, to encrypt the message 12 and by the 
recipient of the communication to decrypt the message 
13. It may also be used by the recipient to 
authenticate a message by havir^ the sender use the 

15 secret key to coo^mte some function ancA as a ttrasage 
Authentication Code (MUC) based upon the mmsage; the 
recipient thus can be assured of the identity of the 
originator, because only the sender and the recipient 
know the secret key used to confute the KAC. DES is an 

20 exeunple of a symmetric cryptographic system. 

In asymmetric (public key) cryptography, shovn in 
TlGKBiE 1(b), different keys are iised to encrypt a»d 
decrypt a message. Each user is associated with a pair 
of keys, one Icey IS (the public key) is publicly known 

25 and is used to encrypt messages 17 destined for that 
user 7 and the other key 16 (the private key) is known 
only to that user and is used to decrypt incoming 
sessages 18. Since the public key nMd not be kept 
secret, it is no longer necessary to secretly convey a 

30 shared encryption key between communicating parties 
prior to exchanging confidential traffic or 
authenticating messages. RSA is the most well*kno%m 
asymmetric algorithm. 
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A digital signature, however, is a bloclc of data 
appended to a message data unit, and allows the 
recipient to prove the origin of the message data unit 
and to protect it against forgery. Some asymmetric 
5 algorithms (for example, RSA) can also provide 

authentication and non-repudiation through use of 
digital signatures. In order to sign data, the sender 
encrypts the data under his own private key. In order 
to validate the data, the recipient decrypts it with 

10 the sender's public key. If the message is 

successfully decrypted using the sender's public key, 
the message must originally have been encrypted by the 
sender, because the sender is the only entity that 
knows the corresponding private key. Using this method 

15 of signing documents, the encrypted message is bound to 
the signature, because the recipient cannot read the 
message without decrypting the signat\ire data block. 
The signature-encrypted message can then be encrypted 
to the recipient using the recipient's public key, as 

20 usual. 

Digital signatures may also be formed using 
asymmetric encryption algorithms as described below and 
as illustrated in FIGURE 2. To sign a message, the 
message 20 is first digested (hashed) into a single 

25 block 22 using a one-way hash function 21. A on*-way 
hash function has the property that, given the digest, 
it is computationally infeasible to construct any 
message that hashes to that value or to find two 
messages that hash to the same digest. The digest 22 

30 is then encrypted with the user's private key 23, and 
the result 24 is appended to the encrypted or 
unencrypted message as its signature 25. The recipient 
uses the sender's public key 26 to decrypt the 
signature 25 into the hash digest 22. The recipient 
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also digest^s (hashes) ttiB menage 20, which has been 
received either unencrypted or encrypted and th^n 
decrypted by the recipient, into a block 27 using the 
se&e one^^^y hash ftmction 21 used by the sender* "Hie 
5 recipient then verifies 28 the sender's signature 

Cheeking that the decrypted hash digest 22 is the same 
as tte hashed message digest 27* 

S^mratlng the sigi»ture fro® the message in this 
vay, that is, not requiring the sender and recipicmt to 

10 enerypt and decrypt the cmtire message in order to 
^rify ^e signature, greatly reduces the aii»>unt of 
data to be encrypted. This is important because public 
key algorithms are generally substantially sXomr than 
conventional algorithms, and processing the entixm 

15 message in order to verify a si^pnature vckuld require a 
significant amount of time, ^e signatxure process also 
introduces redundancy into the messaqe, vhi<^, )>ecause 
tiM message must hash to the specified digest, allows 
thd recipient to detect unauthorized changes to the 

20 irassage. 

A digital signature provides the security services 
of (a> integrity, tecause any modification of the data 
being signed will result in a different digest and thus 
a different signature; (b) origin authentication, 

25 beeause mily the holder of the private key 

cctffespM^ing to the public key used for validation of 
the signature ccHild have sign«l the message; and (c) 
non-r^udiation, as irrevcwable proof to a third party 
that only the signer, and not the recipient or its 

30 es^loyees, could have created the signature. A 

symnetric secret key autbenticator, for exaaq^le the 
X9.9 HAC, does not provide these services, since either 
of the two parties can create the authenticator using 
their shared key. 
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Several of the mechanisms discussed herein assume 
the ability to attach multiple signatures or 
cosignatures to a document. A useful format for this 
purpose, as is well kno%m in the art, is defined in 
5 ••PRCS #7: Cryptographic Message Syntax," RSA Data 

Security, Inc., 1993, which is hereby incorporated by 
reference. Each signature structure on a docxunent will 
contain an indication of the certificate needed to 
validate the signature along with a bit string 
10 containing the actual signature. Additionally, other 

information relevant to the particular signer may be 
included in an individual signature computation. This 
per-signer information may be included in the signature 
computation as ''signature attributes.** 
15 In order for one user to identify another user for 

transmission of a message in a way that ensures the 
second user's possession of a private key, the first 
user must be able to obtain the other user's p\iblic key 
from a trusted source* As is well-*known in the art, a 
20 framework for the use of public key certificates was 

defined in ••X.509: The Directory: Authentication 
Framework, CCITT, April, 1993 (••X.509**), which is 
hereby incorporated by reference. These basic public 
key certificates bind a user's name to a public key and 
25 are signed by a trusted issuer called a Certification 

Authority (CA) . Besides containing the user's name and 
public key, the certificate also contains the issuing 
CA's name, a serial number and a validity period. 
Although X.509 does not impose any particular 
30 structure on the CAs, many implementations find it 

reasonable to impose a hierarchical structure in which 
each CA (in general) certifies only entities that are 
subordinate to it. Hence, we can construct a hierarchy 
of Cas, as shown in FIGURE 3, in which the higher level 
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CAs 31 (perhaps banks) sign the certificates 34 of the 
CAS 32 teneath them (for example, companies) , and the 
lo^st level of CAs 32 sign user 33 certificates 35 • 
At the top of this hierarchy (not shovm) are a 
5 relatively few other root CAs, perha|» one per country, 
that may ••cross -certify* each other's public keys (root 
keys) . 

Various security architectiures define aechani«as 
to construct a certification path through the hierarchy 

10 to dbtain a given user's certificate all CA 

certificates necessary to validate it. Thrae 
architectures share the common characteristic that a 
user need trust only one other public key in order to 
obtain and validate any other certificate. The trusted 

15 key may be that of the top^le^l CA (in a centralized 
trust model) or of the local CA that issued the user's 
certificate (in a decentralized model) . 

Certificates also contain an expiration date. If 
it is necessary to cancel a certificate prior to its 

20 expiration date, such as if the name associatim 

becomes invalid or the corresponding private key is 
lost or compromised, the certificate may be a^^ to 
the OA's certificate revocatiim list (G3RL) or ••hot 
list.** This list is signed by the CA and widely 

25 distributed, possibly as part of the OA's directory 
entry. The certificate r«&ains on the CRL until the 
certificate's expiration date. 

Often certain information concerning an entity or 
CA needs to be made available in a trusted mnner. In a 

30 secure X.SOO Directory, this information would be 

retrieved via standard Directory operations and the 
result would be signed by the Directory. In the 
absence of such a secure X.SOO implementation, this 
information is placed in an attribute certificate. 
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vhich is signed by a CA in the same manner as the 
public key certificate- Attribute certificates would 
be created on presentation of the proper credentials by 
the user. For example, the user would present his 
public key certificate and prove he possesses the 
corresponding private key, as one form of 
identification. Attribute certificates are linked to 
the user's basic public key certificate by referencing 
the basic certificate's serial number and are revoked 
by an identical parallel CRL mechanism. Attribute 
certificates are discussed further in ••X9.30 Part 3: 
certificate Management for DSA,** ANSI X9P1, June, 1994, 
and U.S. Patents Nos. 4,868,877, 5,005,200 and 
5,214,702, which are all well-kno%m in the art and are 
all hereby incorporated by reference* 

An attribute certificate is a structure separate 
from a public key certificate because proper separation 
of duties may often require that the CA that issues the 
attribute certificate be different than the CA that 
issues the public key certificate. A central CA might 
rarely of itself possess the required security or 
authority to "sign for* all of a user's authorizations. 
Having separate CAs generate various types of attribute 
certificates distributes risks more appropriately. In 
addition, the defined attributes may not be required 
^or all domains, networks or applications. The need 
for these attributes and for additional domain-specific 
attributes is determined by each domain* 

The user's basic piU^lic key certificate remains 
X.509 compatible, allowing its use with other 
applications and allowing use of commercial products 
for certificate generation. 

It is desirable to be able to construct a trusted 
organization that utilizes digital signature and 



oert:lflcate sechani^fts to enforce a aeciirity policy 
defined by rules vit&in ^is organizational structure. 

It is also desirable to use digital si^p>ature and 
certificate iiiei^»nims to enco^ industry-wide security 
5 policy and autiiorisation information into tbe 

s4«|^tures and certificates in order to permit the 
verifier of a si^ature to decide wliether to accept the 
signature or certificate as valid, thus accommodating 
ami easing electronic commerce business transactions. 

10 It is fi^^^^er desirable to reduce the risks 

associated vith digital si^ature systems, particularly 
wil^ md<"UMr amart cairds, by building on this use of 
public key c€urtif ieates and attritmte certificates. 

It is further desirable to prevent the tise of such 

15 a digital signature system by any party that might 

purport to '^accept*' a transaction in contravention of 
the applicable authorization certificates vhen that 
party had not signed the applicable "system rules** 
agre^&ent pertaining to that system of coamuxnicating 

20 signer authorization. 

These and other obj^ts of the invention are 
acoooplished in accordance vith the principles of the 

25 invention by providing a system for securely using 

digital signatures in a comnercial crypto^afihic systra 
that allows ii^tustry-^ide eeciirity policy and 
authorization information to be ei^od^ into the 
signatures and certificates by ^oiploying attribute 

30 certificates to enforce policy and authorization 

rmjuirements. In addition to value limits, cosignature 
r«iuir«iients and document type restrictions that can be 
placed on transact imis, an organization can enforce 
with respect to any transaction geographical and 
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^emporal controls, age-of -signature limitations, pre- 
approved counterparty limitations and confirm- to 
requirements by using attribute certificates for the 
transacting user* Restrictions on distribution of 
5 certificates can be set using attribute certificates. 

Certificates can be used also to ensure key confinement 
and non-decryption requirements of smartcards in this 
system. 

10 ^ pTEF DESC RTPTIQN OF THE DRAWINGS 

The above and other objects and advantages of the 
invention will be apparent upon consideration of the 
following detailed description, taken in conj\inction 
with the accompanying drawings, in which the reference 
15 characters refer to like parts throughout and in which: 
FIGURES 1(a) and 1(b) show the prior art use of 
symmetric and asymmetric algorithms for encryption; 

FIGURE 2 is a flow chart illustrating the prior 
art process of a digital signature using an asymmetric 
20 encryption algorithm; 

FIGURE 3 shows a hierarchy of signatiire 
certification authorities; 

FIGURE 4 shows a directory information tree (DIT) ; 
FIGURE 5 shows an example of an authorization 
25 certificate; 

FIGURE 6 is a flow chart illustrating the prior 
art process of verifier enforcement of a transaction 
monetary value restriction; 

FIGURE 7 is a flow chart illustrating the prior 
30 art process of verifier enforcement of a transaction 
cosignatxire requirement; 

FIGURE 8 is a flow chart illustrating the process 
of verifier enforcement of a transaction doc\iment-type 
restriction; 
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FIGURE 9 is a flow Chart illustrating the process 
of verifier enforcement of a transaction geographical 
and tenporal control; 

PI60RE 10 is a flow chart illustrating the process 
5 of verifier enforcement of a maximxm age of sender's 
signature restriction; 

FIGURE 11 is a flow chart illustrating the process 
of verifier and sponsor enforcement of a pre-approved 
counterparty restriction; 

FZGtIRE 12 is a flow chart illustrating the process 
of verifier enforcement of a transaction "confirm-to" 
requir«Bient; 

FIGURE 13 is a flow chart illustrating the process 
of a device's certification of key confinement and non- 
15 decryption; 

FIGURE 14 is a flow chart illustrating the process 
of keeping public keys secret and enforcing signing of 
system rules; and 

FIGURE 15 is a flow chart illustrating the process 
20 of verifying user rules of a transaction. 

Mi!TATI.m DgflCRIPTTO W OF T«E III^BWTI^ 

The following general principles and philosophies 
are reflected in the signature verification model 
25 defined in this invention. First, CiA and user 

certificates can contain attributes that dooument the 
conditions and assumptions under which they were 
created. Verifiers may simply reject all certificates 
and transactions that do not meet their minirnim 

30 standards. 

Also, attribute certificates may be signed by a 
user's "sponsor" to signify that the sponsor's 
signature will be honored for official business if the 
transaction meets the requirements stated or implied by 
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the attributes. Although typically the user's sponsor 
will be the user's employer, the model can be extended 
to include the user's bank, credit card issuer, voting 
bureau, video rental store, public library or any other 
5 entity that might accept the user's signature. This 

sponsor (authorization) certificate is thus the 
electronic equivalent of an **affidavit of legal mark," 
as used in the context of a traditional signature 
stamp. See Robert Jueneman, **Limiting the Liability of 
10 CAs and Individuals Regarding the Use of Digital 

Signatures,** presented to the ABA Section of Science 
and Technology Certification Authority Work Group, July 
2, 1993. 

Furthermore, industries may develop ** industry 

15 policy** statements that establish minimum recpiirements 
for signature verification. All participants vould 
sign these multilateral agreements in order to ensure 
that all counterparties would be bound by the encoded 
restrictions. Normally, sponsor certificates should be 

20 required in all cases, and digital signatures would be 
deemed otherwise null and void in their absence. 
Industry-wide policies would also define (1) relevant 
document types and classes, (2) signer roles and 
titles, and (3) coded symbols for incorporating by 

25 reference standard contractual terms and conditions. 

Moreover, there must be strict adherence to the 
principle that all restrictions can be enforced in an 
entirely automated manner (that is, verification "on 
sight**) , without reference to paper agreements or human 

30 interpretation, sometimes also termed ** fully 

machineable straight- through processing.** In complex 
and/or high-volume environments, this is required in 
order to give these security controls credibility in 
the eyes of audit and legal experts. Reference to 
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trusted third parties should also be minimized to 
reduce verification latency times. 

iQiile these restrictions seem complex, they merely 
reflect oitiinary business procedures made explicit for 
5 purposes of maohine verification. Formerly, such 

controls were enforced inside the sponsor's computer 
systems before sending out the transaction. However, 
vi^ the advent of nuilti lateral distributed 
tranMicti«», tim verifying user is typically off-line 

10 from the sender's sponsor's system, and so the verifier 
m»t ettforce the sp«%sor's authorization model, as 
reflect»l in the attribute certificates. Once this 
methodol^ry is ^ecified, offi^ software vendors will 
devel^ menu-driven systems to create and nonage user 

15 attrilnites, and the cost to i»er organizations will be 
relatively low. 

Oraani&ational Structure in Certificates 

Ihe certificates themselves may reflect the 

20 structure of a sponsor organization. Because many 
auttorization decisions are based on the user's 
position in an organizatimi, the or^uilzationAl 
structure and tim user's position therein may be 
specified as part of a user's name. Nmftes in 

25 certificates are specified in terms of the X.500 
Directory mortal, as follows « 

Thm X.SQO Directory structure is hierarchical; the 
resulting distributed database comprises the Directory 
Information Tree (DIT) , as shown in FIGURE 4. Bach 

30 entry 41 is of a specific object class and consists of 
a set of properties called attributes 42. An attribute 
42 insists of a type 43 and one or more values 44* 
Thus, in an entry of class organization, one attribute 
is the organ izationName; in an entry of class 
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organizationalPerson^ attributes night include title 
and telephoneHumber • 

Each entry also has one or more special attribute 
values used to construct the object's name; this 
5 attribute value is the relative distinguished name 
(RDN) of the entry. An object's distinguished name 
(DN) 45, which is created by concatenating the relative 
distinguished names 46 of all entries from the DIT root 
to the entry, unicpiely identifies the object in the 

10 global DIT. 

Several of the attributes defined in X.500 may be 
usefully included in the user's attribute certificate. 
For example, the object class can be used to 
distinguish between entities (for example users and 

15 roles) whose distinguished names are of the same form. 
Also, the title may be used in making authorization 
decisions. 

In addition to the use of the DZT to group 
entities along organizational lines, X.500 defines 

20 several object classes that can be used to construct 
arbitrary groups of entities. These object classes 
include the organizational role, whose ••role occupant** 
attribute lists the names of the users who occupy the 
role, and the group of names, whose ••member** attribute 

25 lists the names of group members. To convey this 

Information in a trusted way, one could define role and 
group certificates that convey the names of the role 
occupants or group members, respectively, and that are 
signed by a CA, thus enabling use of this feature 

30 outside the context of an X.500 directory system. 

Group and role certificates may be used in 
conjunction with a cosignature mechanism to simplify 
the construction of cosignature requirements. For 
example, a transaction might require the signatures of 
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three occupants of the "purchasing agent role* A user 
may also Indicate the role in i^mich he is acting by 
including the role in the signature comput^ition as a 
(per-signer) signature attribute. The asserted role 
5 may then tie matched against a role certificate (or the 
user's attribute certificate) during %^rif ication. 

Policy Infor mation in Certificates 

It is another embodiment of this invention to 

10 encode information regarding a CA's security policy 
into the attribute certificates of the CA and its 
sutler ibers, so that the verifier of a signature can 
use the information in determining vhether to accept a 
signature as valid. In general, the CA's certificate 

15 vill convey the rules that a CA uses when making 

certification decisions, while the user's certificate 
will <»nvey the information used by the CA when 
ai^lying these rules* 

Attributes in CA certificates can indicate 

20 security policy and assurance information for a 

particular CA. This policy information can also be 
inherited 1:^ suterdinate CAs, allowing Msy 
construction of security dcmains sharing a commoh 
policy* Policy attributes in a CA's certificate might, 

25 among others, include: 

-(1) Liability Limitations: the extent to which a 
CA is liable in the event of various problems (for 
exaa^le, CA key compromise, defective binding) ; this 
might be no liability, full liability or a specific 

30 monetary amoiint. 

(2) Trust Specification: a description of which 
users and CAs a given CA can certify, expressed 
relative to the CA itself (for example, ••all 
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subordinates") r or to the DIT in general (for example, 
**the subtree below Organization ABC**), or to others. 

(3) Required Attributes: a list of those 
attributes in the user's attribute certificates that 
must be verified against a transaction and/or its 
context in order for the transaction to be considered 
authorized. These attributes would be found in the 
certificate (s) of the sponsor and allow a single 
authorization certificate to contain authorization 
attributes for use with multiple applications. Some 
suggested user authorization attributes are defined 
later. 

(4) Allowable Name Forms: a specification of the 
allowable name forms that the CA may certify. This 
information is held as (a) a set of name bindings, 
which defines the attributes that may be used to name 
entries of a given object class (that is, the allowable 
RDH formats for entries of that class) , and (b) a set 
of structure rules, which defines which object classes 
may be adjacent (that is superior or sxibordinate) to 
each other in the DIT, that is, the order in which 
object classes may be chained together to form a 
complete DN* This policy attribute may be used to 
restrict the type of entities that may sign 
transactions. For example, for wire transfer 
applications, it might be desirable to restrict 
signature capability to the organization itself, rather 
than to users within the organization, since this is 
similar to the current mode of operation using DBS 
MACS. 

(5) Cross-Certificates: it may be desirable from 
an efficiency point of view to allow certifying 
entities and as organizations to cross-certify each 
other in order to constrain the length of certification 
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pa^m. On the o^ver hand, it is not desirable to allow 
c^rtif ioatit^ pa:ths to contain arbitrary numbers of 
cross certificates, as it is difficult to determif^ the 
level of trust in the entity at the other end. l^y 
5 certification architectures restrict certification 
paths to contein only ^e cross-c^rtif icate. To 
acc«imodate a wider range of policies, an attribute may 
be a^ed to the attribute oertif icate associated with 
the eross*^certif icate indicating tiuit the cross- 
10 certifier e^qplicitly allo^ the use of 

cross-certificates issued by the CA being cross- 
certified. 

Attributes in a user's or entity's attribute 
certificate may represent the information verified by 

15 the CA when creating the certificate for the entity. 

Policy attributes in a user's certificate might, among 
others, incliKle: ^ 

(1) Binding Information: the criteria used to 
bind the public key to the identity of the entity being 

20 cM^ified. This incl\»les (a) the method of db^livery, 

sudh as being presents in person, by authorised agent, 
by BAil or by another meltbod; (b) the owtJ^iod ot 
idmtif ication, such as by reasonable coaqneroial 
practices, verified by trusted third party, dual 

25 control, fingerprint check, full background 

inv^tigation or another method; (c) the identification 
documents presented to the CA; and (d) the si^ject's 
entity type, that is, individual, corporation, device 
or other* 

30 (2) Trusted Third Parties: the names of any 

trusted third parties or agents involved in the binding 
prooess. 

(3) Roles: it may be useful for authorization 
purposes to indicate which roles (both internal and 
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external to the organization) a user may exercise* 
This is in contrast to a role certificate, which would 
be issued to the role and contain the names of all 
occupants. 

5 (4) Relative Identity: a CA may wish to certify 

only a portion of the DN of an individual* In 
particular, the CA might disclaim liability for 
correctness of an individual's personal name, since, 
under legal Agency principles, the individual's 

10 signature is binding on their organizational sponsor in 
any event. Consider the name: 

C«US; ©-Bankers Trust; OU^Global Electronic 
Commerce; CN- Frank Sudia; TI»VP 
The CA might certify only the validity of the 

15 organization, organizational unit and title portions of 
the individual's distinguished name, all of which are 
easy to verify, while the personal name would only be 
"reasonably believed accurate.** In view of the 
relative ease of obtaining false identity papers, this 

20 avoids the need for prohibitively expensive background 
investigations. Such an identification can be relied 
on in an ordinary commercial setting but not in a 
proceeding concerning a will or inheritance, for 
example . 

25 (5) Absolute Identity: we define relative 

Identity as the user's identity **relative" to his 
organizational sponsor. Put another way, we certify 
all elements of the user's "^business card identity,** 
except his personal name. As a special case, some CAs 

30 might undertake to certify the absolute identity of 
selected users, say the children of wealthy clients, 
diplomats or national security operatives, almost 
certainly bolstered with biometric techniques. This 
would be rare and is presented here only for 
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cOTipleteness in order to round out the ''relative 
identity** concept. 

Auth^jgA^iTO i;nfQriB^tiQn in certjCicat^s 

5 Attributes may convey restrictions that control 

the cm^itions uMler vhi^ a signature is valid. 
Without such restrictions, the risk of forgery vould be 
consittered excessive, since an electronic signature can 
be affixed to almost any digital docusient by anyone 
10 possessing the t»er's smart card and personal 

identification number (PIN) . In the electronic 
envirommnt, the normal contextual controls of docwnent 
creation and physical delivery are either weak or 
nonsxistent. 

15 Even authentic users are hardly trustworthy to 

undertake free^^form offline commitments, and 
organizations will thus %relcome the capability to 
positively restrict the scope of express signature 
authorization. Such authorization attributes might, in 

20 addition to standard X.500 attributes, include 

Transaction Limits, cosignature Requirements, ItocuiMnt 
Types, subject matter restrictions, JUrt:horiz^ 
Si^^tories, Geograi^ical mnd Tttsporal Controls, Age of 
Signature, Pr^-approved Counterparties, Delegati<m 

25 Controls, and Confirm**To R^fuir^^ent. TtMse attributes 
can be encoded in one or more authorization 
certificates signed by the signer's organisatiotml 
sponsor or by an external CA acting on behalf of the 
organization. An example of an authorization 

30 certificate and an associated transaction is sho%m in 
FIGURE 5. 

tlhen a recipient user (verifier) receives a 
transaction 51 from a sending user, the recipient first 
uses the sender's basic key certificate 55 to verify 
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the sender's signature 52 on the transaction 51. As 
will be described in greater detail below, the 
recipient also uses the sender's authorization 
certificate 56, signed by the sender's sponsor 59, to 
ye^j^fy t.he cosignatures 53 and tinestamp notarization 
54 appended to the transaction 51 and to verify that 
the attribute values 57 of the transaction 51 fall 
within the authorized attribute values 58 as specified 
in the authorization certificate 56. 

The user may be subject to transaction limits that 
control the value of transactions or other documents 
that the user may initiate. The user's signature will 
be valid only on transactions originated either up to a 
certain monetary limit or between two monetary value 
boundaries. Accordingly, as shown in FIGURE 6, the 
sending user sends a transaction 601 signed 603 by the 
sender (actually by the user's smart card 600 
containing his private key) and appends thereto an 
authorization certificate 604 . The verifier uses the 
authorization certificate 604 to verify 607 the user's 
signature 603 and to verify that the transaction 
monetary value 602 falls within the transaction limit 
attribute value 605 in the authorization certificate 
604. The verifier also verifies 609 the sponsor 
signature 606 on the authorization certificate €04 
using the sponsor's public key 610. If any of these 
signatures and attribute values does not verify, the 
transaction is rejected 611. If verification is 
complete, the transaction is accepted 612. 

Hith regard to cosignature requirements, 
additional signatures may be required in order for a 
given signature to be considered valid. Quorum and 
weighting mechanisms can be used to construct fairly 
elaborate checks and balances for explicitly governing 
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the level of lirust: in each user. The particular 
se^^^nce or order of required signattires may also be 
^lecified. Referring to FIGURE 7, sdndii^ user A sends 
a transaction 7t>2 signal 703 by his own ^artcard 700 
5 ai^, if user B's cosigtlature is required on the 

transaction 702, signed 704 by the smartcard of user B 
701. Sendir^ user A also appends his o%m authorization 
certificate 705 to the transaction 702. The verifier 
uses the authorization certificate 705 to verify 711 

10 user A's signature 703, and uses the sponsor's imblic 
key 713 to verify 712 the sponsor's signature 707 on 
the authorization certificate 705; if eitter signature 
d«»s not verify, the transaction is rejected 720. If a 
cosi^natiure value 706 is required 714 by ^le 

15 authorization certificate 705, the recipient enforces 
the requireiBient by verifying 715 cosigner user B's 
signature 704 on the transaction 702, and then checks 
cosigner user B's public key certificate 708 by 
verifyif^ 716 the signature 709 of the certificate 

20 issuer, using the issuer's iniblic key 717. If the 

signature of either user B or his certificate's issuer 
does m>t verify, the transaction is re:^ect^ 722. 

The use of cosignatures allows an Mrganizaticm to 
effectively define checks and balances, and to 

25 eaq^licitly si^cify the level of trust' in a user. The 

UM of cosignatures also greatly reduces the risks that 
result frott inadvertent oompremLBB of a private toy due 
to theft, misuse or miEiplacttBient of a s^rtcard or PIN. 
In particular, it is believed that the ability to 

30 r^uire cosignatures, value limits and related cotitrols 
will enable organizations to carefully manage and fine- 
tune all signature authorizations, thereby giving t^em 
all the tools needed to manage and limit their risks. 
Use of cosignatures further allows distribution of the 
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authorization function over multiple locations and 
hardware platforms, with the resultant minimization of 
risks that might result from access control failures on 
one of those platforms. See U.S. Patents Nos. 
5 4,868,877, 5,005,200 and 5,214,702. 

Authorization signatures, which must meet the 
restrictions specified in the signer's certificate, can 
also be distinguished from other cosignatures by 
including the signature purpose as a signature 

10 attribute and by requiring that an indication of the 

signature purpose be included in the data being signed. 
This signature-purpose attribute might require the 
values of: (a) an authorization signature appropriate 
to the document, (b) an authorization cosignature 

15 appropriate to the document, where the cosigner's 

certificate has sufficient authority to authorize the 
docxment, and (c) a witness cosignature, where the 
cosigner's certificate does not by itself have 
sufficient authority to authorize the docxment. 

20 Signature purpose encodings discussed in draft ANSI 

standard X12.58 Version 2 (Appendix) issued by the Data 
Interchange Standards Association (DZSA) , which is 
welI*lcno%m in the art and is hereby incorporated by 
reference. 

25 The user can also be restricted to signing only 

particular document types, such as ordinary 
correspondence, purchase orders, specified EDZ 
transaction types, business contracts, specified 
financial instruments, etc., as defined by 

30 industry-wide policies. It may also be desirable for 
efficiency to exclude certain large classea of 
transactions and documents. Referring to FIGURE 8, the 
recipient enforces the document-type restriction in the 
sender's transaction 801 by first verifying 807 the 
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sender's signat\ire 803 on ^he transaction and by then 
verifying 808 the docuaient type attribute value 802 
within the transaction 801 to enforce the didcument type 
restriction 805 vitliin the sender's author illation 
5 certificate 804. The recipient then verifies the 

auttorization certificate 804 by t^ing the sponsor's 
public key 811 to verify 8A9 the sponsor's signature 
806. If either a sigi^ture or the attribute 
restriction does not verify, the transaction is 

10 rejected 810. 

It is also desirable to add {K>sitive or negative 
restrictions i^ertaining to transaction subject nuitter 
or context class* For example, to restrict an agent to 
signing pur^ut&e orders for s<»iie class of goods (such 

15 as, ftHT exaa^le, office sij^lies) , or to deny authority 
as, for ^ma^lB, in the case of denyiI^r an agent the 
adsility to purchase pornogra{^ic materials. Sxibject 
matter restrictions are enforced by the transaction 
recipient in the same manner as document type 

20 restrictiofw, and may be implicit in many document 
types, yet requiring separate specification for the 
more generic dOCTapient typ#s. 

An or^^iiization can indicate that there are 
specific authorised si^Mtories, that is, that only 

25 specific ii^ividi^ls can "sign for** the organization, 
similar to a staf^bard **corporate resolution" to this 
effeot. This might cosqplement the document-type 
cm^>t, as an additional control on signing of 
"corporate" docu]Mnt**types« This restriction can be 

30 implMsented by sfwcifying that a cosigmature is 
required in i^ich the cosigner's title (in its 
distinguished naiM) miut be equal to one on a specified 
list contained in a authorization certificate. "Hiis is 
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in lieu of naming a list of one or more required 
cosigners* 

Geographical and temporal controls include 
locations and time periods from which transactions are 
considered valid. Use of a local trusted **timestamp 
notary** is assumed. Such a notary would append a 
trusted timestamp to the originator's signature on a 
document and would then sign the result. Thus, 
time-of-day and day-of-week restrictions would normally 
coincide with the work-week of the user's locale. 
Also, location information would be associated with the 
notary so as to restrict access to a specific network 
segment, typically the user's assigned work area. The 
^'granularity*' of location controls would depend on the 
network architecture. The signer or the signer's 
computer system must attach a certified timestamp from 
a specified local server to the transaction, or else 
the verifier cannot accept the transaction and the 
signer's sponsor will not be bound by it. As shown in 
FIGURE 9, the sending user attaches to the transaction 
901 an authorization certificate 902, as usual, an 
authorized timestamp 903 and a time server certificate 
904. The recipient verifies 921 the sender's signature 
905 on the transaction 901 and verifies 922 the 
sponsor's signature 908 on the authorization 
certificate 902. The recipient then (1) verifies 923 
that the timestamp transaction text hash 909 matches 
the result of the text of the transaction 901 hashed 
with a kno%m hash function, (2) verifies 924 that the 
time and date 910 on the transaction timestamp 903 fall 
within the authorized time and date 906 attribute 
values as specified in the authorization certificate 
902, (3) verifies 925 the time server signature 911 on 
the timestamp 903, and (4) verifies 926 the sponsor's 



wo 9^2993 



PCTAUffiWW«r76 



-25- 

si^prntiiTB 912 on ^he time server certificate. If all 
tt^ese conditions are satisfied , the transaction is 
accepted 931; if tMt, the transaction is rejected 930. 

5 Piurtherrore, a document may not be valid unless 

the signature is verified within sOTie specified time 
period. For high-value transactions this age-of- 
signature attribute period would be quite short, while 
for mere non^l transactions, especially those sent via 

10 store-and- forward systems such as X. 400, a longer 
interval (such as two days) would be appropriate* 
FZGUIUE 10 shows enforcement by a recipient of the age- 
of -signature attribute value* The time of verification 
would be provided using a recei^pt 103 sign«i by a 

15 tr\Mted timestamp service 104 containing, at a minimum, 
the recipient's luime and the signattire from the 
original transaction. The verifier must sulmit a 
tin^taaiqped copy of the original signature that is 
dated prc^tqptly after the time and date of the original 

20 tri^action, or else the sponsor will reject it. As 
^own in FIGURE 10, the recipient (verifier) verifies 
121 "^e ^^ftder's si^rMiture 107 on tramiaction 101 
and verifiM the spoMor's signature 115 on the 
autlwrisation certificate 102 « The recipient then . 

25 verifies 122 that the difference between the date 105 
md tijm 106 on the transaction 101 and the date 111 
ai»l time 112 on the timestaiup 103 is within the age-of- 
signature attribute restriction 108 in the 
euithorization certificate 102. The recipient also 

30 verifies 123 that the hash 110 of the transaction lOl 
within the trusted timestamp 103 matches the text of 
the transaction 101. If all these conditions are 
satisfied, the transaction is accepted 130; if not, the 
transaction is rejected 131. 
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A similar concept is that of a minimum age of a 
signature • In this case the signature would not be 
valid until some minimum time after it had been signed. 
This allows for a smartcard to be reported lost and for 
5 a revocation notice to be broadcast to the recipient. 

The control attribute can specify a maximum and /or 
minimum age for the signature • . • 

A **pre-approved counterparties** attribute value 
restricts an entity to dealing only with some specified 
10 set of known trustworthy partners. This is a common 

requirement in dial-up home banking systems, which 
typically require that all authorized payees be 
specified in advance. Another way of stating this is 
that '•free-form transfers" are forbidden. Sponsors 
15 realize that, in case of an error, they stand a better 
chance of successfully reversing the error when dealing 
with a large, solvent and creditworthy party than when 
dealing with a small, unknown and unauthorized one.^ 
Separate certificates can be issued for each 
20 counterparty in order to prevent a competitor from 

obtaining the user's customer list (other than himself) 
in a single certificate. The approved counterparty can 
be coded either as a common name, a distinguished name, 
a certificate number, or the hash value of either the 
25 distinguished name or the counterparty's public key. 

m order to claim the benefit of the transaction, the 
verifier must submit a certificate that matches the 
encoded counterparty value. 

FIGURE 11 shows verification by the user's sponsor 
30 of the user's transaction after receipt by a recipient. 
The recipient (counterparty) verifies 1110 the user's 
signature 1103 on the transaction 1101 and verifies 
1111 the sponsor's signature 1105 on the user 
authorization certificate 1102. If either of these 
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signatures does not verify, the transaction 1101 is 
rejected 1112. If the si^atures verify and the 
transaction is accepted 1113 h/y the recipient, the 
recipient endorses the tramsaction iioi by issuing his 
verified transaction 1114 c«Minter-signing 1116 the text 
11©6 of the original user transaction 1101 and tbe 
sending user's signature 1103, with the recipient's 
certificate 1115 attach»i. In enforcing the pre- 
a^^oved counterparty r^triction in the sendii^r user's 
authorisation certificate 1102, tlie semling user's 
sponsor verifies 1121 the sendit^ user's signature 
1103, as included in the recipient's verified 
transaction 1114, and verifies 1122 the recipient's 
8igi»ture 1116 thereon. If these signatures are 
verified, the sponsor next verifies 1123 the 
counterparty public key hash value by hashii^ the 
recipient's public key 1117 and checking the result 
against one of the authorized counterparty public key 
hash values 1104 as specifi^l in the user's 
authorisation certificate 1102 (the recipient's public 
key 1117 that the sponsor hashes for verification is 
itself verified 1124 irtien the in^nsor verifies the 
recipisnt's certificate). If these conditions are set, 
the transaction is aec^ted 1125. 

file attribute values of delegation controls can 
lisit the types and value ranges of author isatimis that 
a CA nay specify when issuing an attribute certificate. 
They can also serve to limit the scope and depth to 
which a user aiay delegate his signing authority to 
others. For exanqple, a root CA might limit an 
organizational CX to issuing authorizations only to 
allow its end users to sign documents whose document 
types fall into a range of documents related to state 
tax administration. Or a CA might grant some authority 
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to a user with the provision that it can be delegated 
only to another person with the rank of assistant 
treasurer or higher, for a time not to exceed thirty 
days, and without the right to further subdelegate. 
5 Another authorization attribute, called a 

"confinn-to requirement value, prevents the signature 
from being valid unless the verifier sends a copy of 
the verified transaction to a third party, typically 
the user's organizational sponsor or work supervisor, 

10 at a specified mail or network address, and either (a) 
receives an accept/reject message, or (b) a specified 
time elapses. This requirement is similar to a 
cosignature but occurs after the transaction is sent 
rather than before. Such after-the-fact confirmation 

15 could be acceptable in lower risk situations in which 

few transactions would be rejected and in which 
obtaining the cosignature of the third party in advance 
may be unduly burdensome. Or it might be preferred in 
high-'value cases where positive on-line checking is 

20 demanded. In that case, the flow pattern reverts back 
to an on-line rather than an off-line system. As sho%m 
in FIGURE 12, the recipient first, as usual, verifies 
1211 the sender's signature 1203 on the transaction 
1201 and verifies 1212 the sponsor's signat\ire 1205 on 

25 the user authorization certificate 1202; if either of 
these signatures does not verify the transaction 1201 
is rejected 1213. If the signatures are verified, the 
recipient sends 1214 a confirmation message consisting 
of the original transaction 1201 (the transaction text 

30 1202 and the sending user's signature 1203) to the 

user's sponsor 1215, as specified 1204 in the sender's 
authorization certificate 1202. The recipient should 
receive from the sponsor 1215 the same message in 
return as confirmation 1216, but signed 1205 by the 
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sponsor. The recipient then verifies 1217 the 
sponsor's signature 1220 and the confinaation message 
1216, and accepts 1219 the transaction 1201. 

In order to crsate eos^Iex combinations of 
restrictions, a filter ea^ession, which is a Boolean 
or logical expression involving one or more attributes, 
can allow construction of restrictions involving 
nniltiple attributes. 'Wie attribute assertions are 
link^ with the usual Boolean connectives: **aatA**, "or" 
and «not". For example, the sponsor might restrict a 
user to sutanitting transaction with a type espial to 
"purchase order" and a value less than $100,000. 
Assertions may involve either a single attribute value 
(quality, less than, greater than, etc.), multiple 
values of an attribute (Subset, superrat, ete.)# or the 
presence or absence of an attribute in the document. 
Of course it will be appreciated that any or any of the 
described restrictione, as well as others, can be in 
effect at the ssune time for the same document or 
transaction. These restrictions have been discussed 
and illustrated separately for clarity. 

Ttie use of authorisation attrilmtes allows a 
recipient to verify authorization as well as 
autteatication. In such a scenario, the sponsor 
certificates, anchored by the sponsoring organization's 
otftlficate, would be interpreted as authorising "on 
sight" the transaction to which they are applied, 
asstming all specified restrictions are met. 

A set of basic policies must be defined for use 
throughout the financial services industry and other 
industries in order to provide a well-defined, 
predictable level of service for the verification 
process. These policies would be agreed to on a 
multilateral basis by every participating firm and 
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could stipulate that certain of the restrictions and 
authorizations discussed in this section would always 
be deemed to be in effect unless expressly provided 
otherwise. One of the more important elements of these 
5 industry agreements would be the definition and coding 

of document types. This must be done on a per-industry 
basis, since the rules will obviously be much 
different, for instance, for customs inspectors, 
aircraft inspectors, auditors, tax officials, etc* 

10 Certain authorization attributes may pertain to 

the specific content of the dociiment itself. This can 
pose problems for automated machine verification, 
because the verifier's computer may not always be able 
to determine the values of such attributes for a given 

15 document or transaction. Examples include monetary 
transaction limits, dociiment types, and security or 
confidentiality labels. Therefore, it is desirable to 
provide a standard data block, preferably at the start 
of the document or the transaction, clearly encoding 

20 the attribute, for example the stated monetary 
transaction value, docximent type or secxirity 
sensitivity label. This doctiment tag will be appended 
by the signer's computer for the convenience of the 
verifier and as an aid to the verification process. 

25 However, in the event of a conflict between the tag and 
the actual content of the document, the language of the 
docuaent would be controlling. In the case of 
structured transactions, such as EDI transactions, in 
which the document types and monetary values are 

30 already completely machine readable, document tags 
would not be needed* 

As a possible convenience in processing simple 
authorizations, especially where a given user signs 
many similar transactions, it may often be helpful to 
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copy the user's public key out of his basic 
authentication certificate and include it as another 
attribute in an authorization certificate. This 
permits the authorization certificate to serve both 
5 purposes (authentication and authorization) and allows 
th^ sender to omit the basic authentication certificate 
from each transaction. In addition, irtiere a device is 
being relied V9ort to fulfill a given condition, it may 
likewise be advantageous to copy the user's device 
10 public key into the authentication or authorization 
certificate as well, further eliminating the need to 
send the device certificate with each transaction. 

Third Partv Interactions 

15 Additional, useful features of digital signatiires, 

beyond those that can be provided using attribute 
certificates, involve interaction between a signer and 
third parties of various types. 

one such use for digital signatures is electronic 

20 notarization. As discussed above, there will be a need 
to cosign docunuants using a third party that is trusted 
to provide an accurate timestas^ and/or location 
information. Simply relying upon signature originators 
to provide this information in an accurate fashion 

25 leaves signatures vulnerable to fraud based on, for 
^xamplm^ pre* or iK>st-*dating of documents. An 
electronic "notary** would be trusted by virtue of its 
OA's policies to provide this information correctly* 
The multiple signature capabilities already assumed can 

30 be expanded to provide a framework for this service* 

For notarization purposes, timestasqps and location 
information will be included as signature attributes. 
Individual signature structiires may either be detached 
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and stored or, if desired, conveyed separately from the 
document • 

Multiple signatures or joint signatures on the 
dociment itself can also be distinguished from 
** counter signatures,** which are signatures on the 
signature structure in which they are found and not on 
the document itself. A countersignature thus provides 
proof of the order in which signatures were applied. 
Because a countersignature is itself a signature 
structure, it may itself contain countersignatures; 
this allows construction of arbitrarily long chains of 
countersignatures. Electronic notarization would then 
consist of countersigning the originator's signature 
and including a timestamp within the information being 
signed. For very high^-risk applications it may also be 
desirable to require multiple signatures on each 
certificate by one or more CAs, with the signatures 
being performed in independent cryptographic facilities 
and with different private keys. 

Various levels of service can be defined for 
electronic notaries based on the level of data 
verification performed prior to signing (ranging from 
mere existence of the document, in which case 
notarization may be completely automatic, to human 
verification of document content) and based on data 
retention and audit capabilities. 

Another use for digital signatures is for 
delegation or "power of attorney" certificates. 
Because users are often tempted to entrust their 
devices or smartcards to others, for example, 
secretaries or co-workers, when the users go on 
vacation, the frequent situation, in which one user 
obtains another user's smartcard and PIN, exposes the 
smartcard to possible misuse. The system therefore 
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facilitates the Issuance of power of attorney 
certificates that allov a delegate to associate th« 
signature of his own snartcard with the atfthority of 
the delegating user. Tlie |>over of attomciy certificate 
would include at a minimuiB the name of the delegator, 
identification of the delegate's public key certificate 
and a short validity period, and would be signed by the 
delegator. Another possibility is for the delegate to 
create a new key pair exclusively for use with the 
delegator 's signature, witJi the new public key included 
in the power of attorney certificate, lliis would 
eliminate any potential confusion between use of the 
delegate's private key on behalf of the delegator and 
on his own iwhalf. 

The problem of hailing over smart carte can be 
greatly r^uc^ by providing a workable alternative 
that preserves the principle of individual 
accountability, wide implementation of this featitre 
will make practical the disallowance of smartcard 
loans, a highly desirable goal. 

The use of delegation certificates discussed above 
io^lies that the user is acting as a CA. In scose 
oases, particularly those in which the transaction 
crosses organisational bovandaries, there may be concern 
that the level of controls and auditing available with 
the individual user's cryptographic device (for 
exaa^le, a smart card) is not sufficient. In su^ 
cases, delegation certificates could be issued by a CA 
upon request of the delegator as normal authorization 
certificates. This also allows the delegation 
certificates to be revoked using the standard CM, 
mechanism. Users' certificates might then indicate a 
list of possible delegates, and the de lege ti«i 
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certificate itself would contain an attribute naming 
the de legator. 

In exercising the power of attorney, a user may 
indicate that he is signing for another user by 
5 including in the document or transaction a 

**signing-f or** signature attribute, that is, the name of 
the user being signed for. There must be a valid 
delegation certificate authorizing the signer to act 
for the user being signed for. Delegation is also 

10 useful in connection with a cryptographic module in a 
user's personal computer. Hashing and signing a 
dociiment should ideally be a unitary operation in order 
to prevent siibstitution of a false hash via software 
hacking. However, the typical smartcard lacks the 

15 computing power to hash a very long document. One 

solution is to let the smartcard delegate this function 
to the cryptographic module using a very short-lived 
delegation certificate valid for only a few minutes* 
This certificate is signed by the user's smart card and 

20 indicates that the user of the smart card has allowed 
the delegation. See, for example: Cesser, M. , A. 
Goldstein, C. Kaufman and B. Lampson, "The Digital 
Distributed System Security Architecture,** Proceedings 
of the 12th National Computer Security Conference, 

25 1989; Gasser, M. and E. McDermott, **An Architectlire for 

Practical Delegation in a Distributed System,** 
Proceedings of the 1990 IEEE Symposium on Security and 
Privacy. 

30 Non-Public Public Key 

A more basic problem, however, is ensuring that 
all possible recipients will actually employ the 
certificate- and attribute-verification methods 
described above. Although these methods allow 
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sj>onaorin9 organizatiwis to protect thence Ives, their 
users and those with whtm they transact froa liability 
bas^ upcm falsified traf»£ictions by allovinig th^ to 
verify the identity and qualifications of those with 
5 wh^ they transact and the i^aracteristics of 
transactions prior to transacting, there is no 
guarantee «iat all recipients will actually so verify* 
If a recipient acts upon a transaction wit^<Hit first 
verifying the attributes of ^th the sender and the 

10 traiwaction, aurid if the sender is later found to have 
sent a fraudulent or unauthorized transaction, the 
r^ipient could then claim liability frcna the sender or 
its sponsor by claimir^ that the recipient was tmaware 
of any r^^irement for authorization verification of 

15 the user^s basic signature* One way to ensure that 
spof»ors and other entities are protects froa 
liability in such a situation is to require that the 
signer include the hash value of each of his identity 
and authority certificates as attributes within his 

20 signature. This can prevent a verifier froa claiaing 
that he was unaware of such certificates and of the 
restrictions they iii^oae. However, the sitpwr ai^^t 
(intentionally or unintentionally) omit to do ^is. 
Another more emphatic way to ensure verifier craigpliance 

25 is to prev«it the root key, the public key of tJie 
ulttiMte authority, that is, the highest* level 
certifying authority, which key would-be verifiers will 
need in order to verify any |«rt of a transaction, frcwi 
being distributed to a user (or to the user's device or 

30 saartcard) unless the user contracts with the 

cryptographic system and agrees to verify all parties 
and all transactions in accordance with the 
preestablished rules. In this way, the users are not 
technically forced to verify all parts of their 
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transactlons. However, not verifying their 
transactions in full would violate the contract between 
the users and the cryptographic system and would 
thereby absolve all other parties to the cryptographic 
5 system, for example a sponsor whose employee acted 

without authority, from liability. The non-verifying 
recipient would then bear all the risks of such an 
unverified transaction himself. Furthermore, because 
the root key of the system authority is considered a 

10 trade secret, no one who has not signed the system 

rules agreement may possess a copy of it, and no one 
could claim to have verified any part of the 
transaction. This would make it far more difficult for 
the **outside** verifier to claim that he had incurred a 

15 loss by ^treasonably relying** on the transaction, even 

if it was in fact valid. This art of keeping the 
system root key as a trade secret lends particular 
force and effectiveness to all the restriction and 
authorization methods described herein. It is believed 

20 that the possibility of incurring the potentially- large 
liability for valuable transactions will persuade users 
to employ the methods of attribute verification of this 
invention. 

25 Restgietiong on Certificate Distribution 

Users and organizations must be able to restrict 
the distribution of all types of certificates for a 
number of reasons. First/ the certificates often 
contain confidential business information that the user 

30 or organization prefers not be shared with others and 
that is nevertheless being shared with the verifier 
through the certificate, albeit only for the limited 
purpose of signature verification. Also, users' basic 
privacy rights may be violated if their public keys and 
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netvork addresses are published. For exeuaple, tttmy may 
be flooded with unsolicited business proposals and 
advert isenrents once their public keys ^ce dissoninated. 
Purthermore, the organization qiay have a general policy 
5 against giving out user identification numters and 
public keysr k^cause they may be used as starting 
points for various types of security attacks. 

"Ehis fxinctionality may be ii^lemctnted as an 
attrib^ite in user's certificate. If the **distribution- 

10 resteiction** attribute is TRtffi, the user/ issuer grants 
Smrmission to use the certificate (which ccmld be an 
authority or a public key certificate) only for * 
slep»ture verification; distribution or further 
publication is prohibited. Other ways to specify this 

15 rratriction mi^t include placing ^e attribute in the 
^^utization's certificate, publishing the restriction 
as part of the industry-specific policy, or (in a true 
X.500 iiiq;>lementation) using the X.500 access control 
list mechanism to restrict access to the certificate. 

20 Altho^^ some existing general legal basis for 
enforoing this restriction mi^it be found under 
ccqpyri^t lew, that is, if the certificate is declared 
as an unpublished work for whi<^ a license is granted 
only to the naiMd verifier, a firmer legal basis will 

25 still be desirable. 

smagticard Rftguirements 

ThrnxB are some additional requirements on 
smartcards when used with commercial digital signature 
30 systMHS. 

The first requirement is private key confinment 
and self -certification. That is, the user's private 
signature key must never be allowed to leave the smart 
card. Only in this way can it be assured that theft of 
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the key cannot be accomplished through purely 
electronic means without leaving any evidence. This 
principle of private key confinement is vital to the 
concept of non-repudiat^ion. 
5 Thus, as illus'tra^ed in FIGURE 13, when providing 

a public key 1303 to be certified, the card 1301 must 
attest that ^e card 1301 is tamperproof and possesses 
a key confining design. Proof can be provided via a 
^device certificate** 1302 stating that the card 

10 originates from the specific manufacturer or product 

line. The public key 1308 of the device 1301 must then 
be certified by the manufacturer or by a CA designated 
by the manufacturer. One likely approach to creating 
this device certificate would be to generate the device 

15 key pair during fabrication of the smartcard so that 

the corresponding device certificate 1302 could also be 
included on the card. The device certificate 1302 
certifies the properties 1304 of the card, and the card 
generates a key pair 1303,1309 which is to be used by 

20 the user of ^e card and which the user can have 

certified as his own by any appropriate desired CA. 
Then, when submitting a newly generated public key 1303 
for certification, the device private signature key 
1305 would be used to countersign 1306 the certificate 

25 request data 1307, which is already signed by tHe 
newly«-generated user private key 1309. 

Also, in a case in which the government requires 
that all decryption keys be escrowed, the card should 
be able to certify that it is incapable of decryption. 

30 This **signature only** certification can be implemented 
through the same mechanisms described above, thus 
allowing the user^s signature key to remain exempt from 
escrow rec^uirements. Because it is doubtful whether an 
escrowed key retains any value for non-repudiation 
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servioes, ^is ^rtlflcation is vital in order to 
prevent the «isr»»ture key's disclosure through possible 
mishandli^ during an escrow process. 

&nartcar<te should also be required to guard 
5 against unauUiorized use of personal idsntif ication 
jm^^6 (PZK8) . Nornally, a ss»rtcard is protected 
against unaisthoriaed use by a PIN, the equivalent of a 
pas^r^d. Typically, a PIN is changeable only by the 
u»cir and must be a specified lei%gth, but typically 

10 nothing prevents the user f roo setting the PIN to a 
trivial Ruaiaer, for exeunple all I's or 121212. 
Smarteard vendors should be requested to iaiplement PIN- 
change routines that insure non-trivial PINs without 
repeating digits or obvious patterns. Making the PIN 

15 relatively long (at least 6 digits) and non-trivial 
reduces the fiance that the card can be operated by 
soQteone finding or stealing it. Support for a 6-digit 
PIN rsquirMient can be found in '*X9.26: Financial 
Institution Sign-On Authentication for Wholesale 

20 Financial Transactions", ANSI, 1990, which is well- 
kn«%m in the art and is hereby incorporated by 
r<»ferenee «sd which sets forth the "one-in-a-wlllion" 
standard ttet states that a log- in mechanism may be 
consider^ secure If, among other things, an attscker 

25 has no more than a one-in-a-million chance of guessfz^ 
the aarrmct password and if the system takes evasive 
actiMt to prevent repeated guessing. Furthermore, 
smartoards should be required to take "evasive action", 
for example, shutting down for a period of time or even 

30 erasing private keys, if too many incorrect PINs are 
entered 1^ an unauthorized user. 

It could also be made a reqpiirement that smarteard 
manufacturers use biometrics as more secure methods of 
identification. Extensive work is currently being done 
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in the areas of voiceprint and fingerprint 
identif ication, as a supplement to PINs. However, 
while the rates of false positive and negative still 
must be reduced, the main problem lies in securing the 
5 biometric input device and its data channel so that 

they are immune to capture and replay of the biometric 
data* This is not a problem when the biometric device 
is embedded in a concrete wall, for example in an ATM 
or door access system, but it remains a serious problem 
10 in typical commercial office settings. Ideally, the 

card and biometric input device will each be 
tamperproof cryptographic modules that can certify 
themselves and establish secure channels with each 
other » 

15 smartcards should also be able to maintain an 

••audit trail, or an internal log of recent actions, 
containing at a minimum, a timestamp, transaction 
amoxint, type code and message digest. This information 
can be compressed into 40 or so bytes so that a 400* 

20 record circular log would consume around 16K bytes* 

This log would be uploaded and checked only on receipt 
of a signed request from the card issuer over a secure 
channel. Also, the card would not delete the old log 
until it received a signed confirmation from the issuer 

25 stating that the uploaded log had been received intact, 
^is control mechanism will deter forgery, reduce the 
damage that can be caused by a forger, and allow 
unauthorized or questioned transactions to be 
investigated more quickly and easily. Since most or 

30 all transactions occur off-line from the issuer, the 
card is the best witness of its o%ni actions. 
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g ynfeya^lring xaaesa to Hhe gublic Itev ef the Root 

1^ sJ^eim in FIGISfS 3, in a particular 
czypt^ffaiAiic system, tltere may a hierarchy of 
5 certifying wthorities (31-33) issuing certificates 34, 
35. in a larger system the iHmber ef certifying 
authorities aaid the depth of the hierarchy wmlA be 
mu^ greater. In the structure shown in FIGURE 3 the 
certifying authority A (31) is tlio root certifying 

10 authority, with all other certifying authorities being 
below it. ha noted in the description of FI^IRE 3, the 
public key Of certifying authority A is well Jawvn, In 
a systm ^ere certifying authority A accepts liability 
for any transactions in the system based on infon^tion 

15 in e«^if ioates issued by A, it %rould be useful ai^ 
desirable for certifying authority A (the root 
certifying authority) to control access to its public 
key. By doing so, certifying authority A could enforce 
rules on the system which %rould ensure the well-being 

20 of the structure of the system. Various methods for 
controlling access to the public key of a certifying 
authority are now describe. 

With reference to FKi^OtS 14, in a cryptographic 
systm, a certifying authority (CA) 1402 issues user 

25 idmtity cmrtifioates 1404 to ueers (for exaaple, user 
1438). ef tte cryptographic system. Certifying 
authority 1402 has a private key 1406 and a public key 
1408. The private key 1406 is used to digitally sign 
the certificates 1404 with certifying authority's 

30 * digital signattire 1410. Certifying authority 1402 may 
be any certifying authority in a hierarchy of 
certifying authorities, such as, for example, that 
shown in FIGiTRE 3 . 

certifying authority 1402 determines information 

35 about users of the system, and, based on that 
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information, issues the certificates 1404 to those 
users. A certificate 1404 issued by certifying 
authority 1402 to a user 14 38 contains user information 
1410 including the user's public key 1412 and 
5 certifying authority's policy information 1414 

regarding that user. In order for the information 
contained in the certificates 1404 to be verified by 
other users of the system, these other users must have 
access to the public key 1408 of the certifying 

10 authority 1402. 

Effectively, certificates 1404 issued by 
certifying authorities are used by users of the system 
to identify themselves to other users of the system so 
as to facilitate transactions vithin the system. A 

15 recipient (a system user) receiving a transaction 1440 

from another system user 1438, where the transaction is 
accompanied by a certificate 1404 issued by certifying 
authority 1402 can rely on information in the 
certificate 1404, essentially because the certifying 

20 authority 1402 which issued the certificate 1404 

vouches for the information in the certificate and 
accepts liability for certain transactions which rely 
on information in the certificate. If the certificate 
1404 includes policy information 1414 of the certifying 

25 authority, this liability is only -accepted by tbm 

certifying authority 1402 if the recipient had a valid 
copy of the certifying authority's public key 1406 and 
if the recipient followed the policy 1414 described in 
the certificate 1404. 

30 Thus, for example, suppose that after verifying to 

its satisfaction the identity of user A (1438), 
certifying authority 1402 issued a certificate 1404 to 
user A (1438). The certificate includes the public key 
1416 of user A (1438), a policy 1414 of certifying 
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autbority 1402 with respect to user A and is digitally 
signed by certifying authority 1402. Su^ose, fier 
eid^le, that the policy 1414 in the certificate 
pacified that user A can only enter into transactions 
5 on weekdays from nine in the ntorning to five in t)^ 

afternoon. A recipient 1424 of a transacti^ 1440 by 
user A 1438 and Ute certificate 1404, can perform the 
tr^isaetien with the knowlet^e that certifying 
authority 1402 w»ald accept li^ility for the 

10 transaction if (a) the recipimt verified tiie policy 
1414 for t^e transaction, that is, if U&e recipient 
verifies ^at the trax%saction is taking place within 
the allowctd title bounds, and (b) the recipient had a 
^lid TOpy of the j^iblic key 1408 of the certifyixig 

15 authority 14«2. In other wordte, if the recipient does 
not ^leck the trai^aetion with respect to the policy 
then the transaction is invalid. Further, even i£ a 
recipient c^iecks the transaction from user A and the 
trai»action is allowed by the policy of the certifying 

20 auth^ity with respect to user A (as specified in the 
certificate), the certifying authority 1402 is not 
liable for the transaction if the rMipient was not in 
possession of a valid c^y of the certifying 
authcarity's public key 1408. 

25 the cryptographic system also includes various 

sponrors 1418 ^o also issue certificates to users, 
'mese sponsor-issued certificates are also known as 
authorisation certificates 1420. These certificates 
1420 function, inter alia, to specify the rules or 

30 policies 1422 of the sponsor issuing thea.^ These 

authorisation certificates 1420 can be separate and 
different from the identity certificates 1404 issued by 
the certifying authorities (even thoi»gh the identity 
certificates may contain policy requiremcmts of the 
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certifying authorities) . A user may have only one 
identity certificate 1404 issued by a certifying 
authority 1402. However, a user may have numerous 
authorisation certificates 1420 issued by one or more 
5 sponsors 1418. 

When a recipient receives a transaction from 
another user of the system, the recipient should also 
verify all sponsor policies included in authorization 
certificates included with the transaction from that 

10 user. Thus, in this cryptographic system, users are 
rec[uired to enforce the rules (policies) of the 
certifying authorities and sponsors in the system. 

As noted above, in order for the information 
contained in the various certificates to be verified by 

15 users of the system, these users must have access to 

the public key 1408 of the certifying authority 1402 or 
sponsor 1418 that issued the various certificates. In 
order to enforce the rules of each certifying authority 
and sponsor in the system it is necessary to limit the 

20 access to the public key 1408 of some of the certifying 
authorities* In particular, it is necessary to limit 
access to the public key of the topmost (root) 
certifying authority 1402. 

Accordingly, the root certifying authority 1402 

25 keeps its public key a trade secret, and in order to 

Obtain the public key of the root certifying authority 
1402, a user (potential recipient) 1424 wishing to 
undertake transactions in the system must obtain the 
certifying authority rules 1426 issued by the root 

30 certifying authority. Recipient 1424 must hash these 
rules to form hashed rules 1428 which it must then 
digitally sign to produce a signed copy of the hashed 
rules 1430. This digitally signed copy of the hashed 
rules must be returned to the root certifying authority 
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1402. By these actions^ the recipient 1424 agrees to 
abide by the nuXes ot the certifying authority 1402 
%r&lch it has just si^^. The root certifying 
authority 1402 amy also require that the recipient X424 
5 also c^tain, sign an4 return rules from other 

certifying aut^riti€» in the systra as well as frOT 
sensors in the systoi. For example, recipient 1424 
nay also be retired to obtain sponaor rules 1432 from 
sponsor 1418 and return a signed copy of these rules 

10 1434 to the sponsor 1418. 

<^ce the root certifying authority 1402 is 
satisfied that it has received a valid copy of the 
systm rules signed by the recipient 1424, the root 
certifying authority issues its piddlic key 1408 to the 

15 recipient 1424. 

The root certifying authority public Jcey 1424 may 
be issued to a recipient in a number of ways. In 
preferred embodiments the recipient is provided with a 
sesure device 1436, for example, a smartcard. In one 

20 preferred «iibodiment the certifying authority public 

}smy 1408 is immediately available in the secure device, 
so that cmoe the recipient 1424 obtalM the device, he 
has the root certifying authority public key 1408. In 
another preferred embodiment, the certifying authority 

25 public key 1408 is in the device 1436 in a disabled * 
f OTm,, and the root certifying authority 1402 enables 
the key 1408 in the device upon receipt and 
verification of the signed rules 1430. 

In some oases it is useful for the root certifying 

30 authority public key 1406 in device 1436 to expire or 

to become inaccessible after a certain time period. In 
th^e oasM, in order for the root certifying authority 
to reactivate the key 1406, the recipient 1424 must 
again obtain, sign and return the rules of the root 
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certifying authority 1402. These rules may be 
different from the rules previously signed* 

Different certifying authorities, including the 
root, may also require that other conditions be met by 
5 potential recipients before they are given access to 

the public keys of those certifying authorities. 
However, included in the system rules is an agreement 
by anyone signing the rules to keep them a secret* 

10 cost Recovery 

The rules can also include agreement to pay for 
use of the system. Thus, when a user obtains a valid 
key (by agreeing to follow the rules of the root CA of 
the system) , these rules can enforce agreement to 

15 comply with the payment scheme of the system. 

A cryptographic system can link the operation of 
the system with associated payment by users of the 
system for the transactions they perform and accept. 
The payment for a transaction is made, for example, in 

20 the form of a pre*paid account, an agreement to be 

billed, or a contemporaneous payment of digital cash to 
various parties in the system. For example, a 
particular operations such as digitally signing a 
transaction may cost a user a certain amount to be paid 

25 to the certifying authority which issued the 

certificate which guarantees that user's identity. 

Some digital payment functions can be built into 
the devices containing the public keys. Since user's 
private keys are typically kept in secure devices (for 

30 example, smartcards) , the secure devices can be used to 
maintain a current digital balance for each user. This 
digital balance can be a debit or a credit amount. 
Every time a user digitally signs a transaction using 
his secure device, a certain amount is deducted from 
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that user's digital balance. If the secure device is a 
debit device, then when the user's digital balance 
reaches zero the device wmild become disabled a?^ no 
lonter able to sign for the user. The iaser would taten 
5 hav6 to obtain further digital credit from a certifying 
authority or scmte other sponsor in the systan. If , on 
the other hand, the secure device is a credit device, 
then the user might be required to perform a payment 
transaction to the certifying authority at certain 

10 regular intervals, for example, daily, weekly or 

monthly. Since the digital csredit amount is available 
from the seciure device, the certifying authority could 
be assured that the transaction is for the correct 
amount. A user who does not perform the required 

15 payment transaction would be listed in a CRL as being 
suspended or revoked and trould no longer be able to 
perform transactions in the system. 

Digital payment on a per transaction basis is also 
achieved using a confirm-to transaction. The user's 

20 authorization certificate would list the confirm-to 

address of the payee. Once the transaction occurs the 
payee is notified and can deduct payiMnt from the 
user's account. 

25 Price Information 

Since a user has agreed to pay fees and royalties 
associated with the system, the user can also be 
provided with flexible pricing and billing information. 
User-specific pricing policies can be isqplM&ented 

30 using certificates. Certificates issued by sponsors 
and certifying authorities can include payment and 
pricing policies for particular users. For example, a 
certificate might include a list of prices for certain 
transactions (including, for example, signing using a 
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particular private key, verifying using a particular 
public key, or checking the revocation status of a 
particular certificate) , a discount rate for particular 
users, a discount rate for transactions with certain 
5 recipients, and rates for bulk transactions. Some of 
the billing is perforaed by the secure devices of the 
users whereas other billable events can arise from 
actions performed by recipients of transactions. 

In order to implement certain pricing policies, a 

10 certificate may contain various digital fields. For 
some policies, these fields include a revocation 
service address, a revocation service fee, and a 
transaction confirmation fee* The revocation service 
address is similar to the confirm*to address, but is 

15 used only to confirm the validity of the certificates. 

That is, the revocation service screens for attempted 
transactions based on certificates that have been 
withdra%m. The Revocation Service Pee is the fee 
charged for this service. 

20 Examples of these fields are: 

(a) Private_Key_Signing_Fee » $0.50 

(b) Public_Key_Verify_Fee « $0.50 

(c) Revocation_Service_Addres8 » 

rev^checkebtec • com 
25 (d) Revocation_Service_Fee » $0.50 

(e) Conf irm_Service_Fee « $0*50 
All fees can be stated as flat fees or as a fee 
per some amount of base transaction amount. For 
example, a fee can be specified as ''SO.SO** or as "$0.50 
30 per $1,000 of base transaction amount". 

Given the above examples, a recipient receiving a 
transaction could send the associated certificates to 
the revocation service address and would be billed at 
the rate specified by the service fee. 
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In order to charge for a confirm-to transaction, a 
certificate can also contain a transaction conf imation 
t^, for example, 

transact ion_Confirmation_Fee « 
5 ($O.50 per 

$1000 

transaction 
emmmt) 

In this case eac^ cmif irmed transaction would cost 

10 the recipient the a^ropriat^ fee. 

In some instances a recipient may receive a 
transaction that is too ei^nsive and which It would 
therefore reject. Accordir^ly, a digital field 
indicating permission to bill the sender, the field 

15 toeing signed 1^ the seiner, is also included. This 
field could include the sender's account number and 
other information including a maximum acceptable 
billing rate etc. Itois "bill-sender* field would 
ai^ear as an attribute in the sender's signature block. 

20 

Tnteiiectual Property Licensing 

rules may also include agreement to pay for 
all intellMtual property used by a user. For example, 
a systoi may offer a user patented transactions, 

25 services or algoriUms, ccqpyrighted materials, axid the 
liks.- In order to a user to obtain a public that 
would enable access to ^is intellectual property, the 
user must sign the user zrules agreeing to pay for use 
of the property. 

30 For example, in one embodiment, the secure device 

contains many un-activated services (for which payment 
is required) . Bach use of one of these services 
requires payment in the form, for example, of digital 
cash, either by an internal transaction in the device 
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or by some transaction with another user of the system. 
In order to obtain the device, the user nust digitally 
sign a set of rules (using a private key in the device 
and unique to the device and therefore the user) . By 
5 signing these rules, the user agrees to make the 

payments as required. 

Signer Im posed Policies and Rules 

A user of a cryptographic system may have an 

10 identification certificate (issued by a CA) and one or 
more authorization certificates (issued by OAs or 
sponsors of that user).. Each of these certificates has 
policies of the issuing party, and a recipient of a 
transaction including any of these certificates is 

15 expected to verify that the transaction obeys all the 

rules specified in the certificates. It may be the 
case, however, that for a particular transaction, a 
user wishes to have more restrictive rules applied than 
are allowed by the certificates. For exanqple, a user 

20 may be allowed to approve all transactions of $1 

million or less, but may wish to approve a certain 
transaction only if its value is less than $1,000. 
Alternatively, a user may be allowed to approve certain 
transactions alone, but for a specific transaction the 

25 user may wish to require one or more co-signers* In 
support of this feature, the cryptographic system of 
the present invention provides users with the ability 
to add user rules, attributes and restrictions to 
transactions. 

30 The user rules cannot permit transactions to be 

approved that would not otherwise be allowed* 
Therefore a recipient must always apply the most 
restrictive rules to every transaction* For example, 
if a user's certificate allows transactions up to 
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$X,&O0 and th« user rules ^ecified transaction values 
of up to $1 rndkllion, olearly the $l,dDO limit should 
ai^ly. "mis ean be acshieved, for exa^le, ^ tfee 
recipient a^lyit^ all of t^e certificate rul€» first 
5 ai^ th^, if tim transactitm is still valid^ ^plying 
all of the user rules. Applying the user rules first 
and ^^n the certificate rules will also prcN^ce a 
cor reot result. Wsm^^r, since boolean cosibinations of 
rules mi^ restrictions are supported, interleaving the 

10 u^&r and certificate rules m^y produce an incorrect 
r€^lt if not carefully perforstcKl. 

FZ€IIRS 15 s^ovs verification of a user transaction 
vhich incl\2des vMer-»a|9lied rules. A user transaction 
1502 includes transaction text 1506 describing the 

15 transaction to be perforsu^ by a recipient. The user 
aiq>ends to the transaction text 1506 a set of user* 
supplied rules 1504 which the user wants verified by 
any recipient of the transaction 1502 . Then the user 
digitally signs the combination of the transaction text 

20 1506 and the rules 1504 to form the transaction 1502, 
forming a user signature 1510 which is a^^ended to the 
traiwaction* 

The transaction 1506 is then sent, along with any 
reguir^ spm»or and/or CA certificates, for exasqple, 

25 with CA certificate 1508 and sponscv certifi^te 1S09, 
to ajrecipient Who must ^en verify the traraacti^m* 
To do this, m%e recipient verifies 1512 the usmt's 
signature 1510 using the user's j^iblic key 1514 from 
the CA certificate ISOB. If the usmt's sigiwture is 

30 accepted, verification continues, otherwise the 
transaction is rejected 1514. If verification 
cmtinues, the recipi«tt verifies 1516 the CA's 
signature 1518 using the CA's public key 1520. If the 
CA's signature is accepted, verification ccmtinues 1522 
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with the checking of the rules in all certificates and 
those supplied by the user, including sponsor 
certificate 1509. Otherwise, the transaction is 
rejected 1514. If verification continues, the 
5 recipient verifies 1522 the transaction against the 

rules in the CA certificate 1508, sponsor certificate 
1509 (and in any other certificates associated with 
this transaction) • If any of these rules are not 
satisfied the transaction is rejected 1514, otherwise 

10 verification of the transaction continues with the 

verification of the transaction with respect to the 
user-supplied rules 1504. Only if the transaction 
satisfies the user provided rules 1504 is it accepted 
1526, otherwise it is rejected 1514. 

15 The user-supplied rules 1504 can be any 

combinations of the rules known to the system, 
including, but not limited to co-signature 
requirements, temporal limits, transaction amount 
limits, confirm- to requirements and the like. 

20 In some environments users may create sets of 

rules or default rules for themselves for use with 
particular types of users or transactions. These sets 
of rules or defaults may be automatically attached to 
all transactions from those types of users or 

25 transactions. For example, a user- who is bank manager 
may determine (from experience) that for all 
transactions by new tellers that she countersigns, she 
is going to apply more restrictive rules than the bank 
requires. She would then store these rules in her 

30 system as a default for those kinds of transactions 
that she signs or countersigns. 

One skilled in the art will appreciate that the 
present invention is typically practiced using 
electronic devices such as digital electronic computers 
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and the like, and that the certificates, transactions, 
messages, signatures and the like are digital 
electronic signals generated by the electronic devices 
and trwismitted l»tween t^ electronic devices. 
5 ^uis, a method for securely using digital 

signatures in a owroercial cryptographic system is 
providted. One skilled in the art will appreciate that 
the preset invention can be practiced by other than 
the described esdMdiments, which are presented for 
10 imrpoees of illustration and not limitation, and the 
preeent invention is limited only by the claims that 
follow. 
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What is claimed is: 

1. In a cryptographic system wherein a 
certifying authority issues digital certificates 

5 identifying users of said system, said digital 

certificates being digitally signed with a private key 
of said certifying authority to form a digital 
signature and requiring a public key of said certifying 
authority in order to verify said digital signature, 

10 and wherein a user transaction in said cryptographic 

system requires verification by a recipient of said 
user transaction, said verification based on 
information in said digital certificates and requiring 
said public key, a method of controlling access to said 

15 public key comprising the steps of: 

denying access to said public key; 
providing said recipient with at least one message 
containing rules of said system, said rules including 
maintaining secrecy of said public key; 

20 by said recipient, digitally signing said at least 

one document, by which said recipient agrees to said 
rules; and 

in response to said digital signing, permitting 
said recipient to utilize said public key. 

25 

2. A method as in claim 1 wherein said step of 
providing includes the step of providing said recipient 
with a secure device containing said public key, 
wherein said public key cannot be obtained from said 

30 secure device. 

3. A method of enforcing a security policy in a 
cryptographic system, said policy requiring controlling 
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access to a public key, said method comprising the 
steps of: 

denying access to said public key; 

providing a recipient vi^h a message containing 
5 rules of said cryptographic system, said rules 

including maintaining secrecy of said public key; 

by said recipient, digitally signing said 
dociuient, by which said recipient agrees to said rules; 

in response to said digitally signing, permitting 
10 said recipient to utilize public key* 

4. A method of enforcing a security policy in a 
cryptc^raphic system, said policy requiring controlling 
accede to a public key, said method conqprising the 
steps of: 

providing a recipient with a dociiment containing 
rules of said system and with a secure device 
containing an inactive form of said public key, vrt&erein 
said public key cannot be obtained from said device; 

by said recipient, digitally signing said 
docxament; 

in response to said digital signing, activating 
said imblic key in said secure device. 

5. A method of enforcing a security policy ixi a 
cryptographic system, said policy requiring controlling 
access to a public key of a certifying authority, said 
method c«qprlsing the steps of: 

by said certifying authority, 

providing a user with a message containing 
rules of said system and with a secure device 
containing an inactive form of said public key, 
wherein said public key cannot be obtained from 
said device; 



15 



20 
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by said user, 

indicating an intent to follow said rules, 
said indicating including the steps of: 

hashing said message to obtain a hashed 

5 document ; 

digitally signing said hashed document to 
form a digital agreement; and 

returning said digital agreement to said 
certifying authority; 
10 in response to said indicating by said user, 

by said certifying authority, activating said 
public key in said secure device. 

6. A method as in any one of claims 1*5 wherein 
15 each user of the system has a private key, and wherein 

said rules include at least one of rules requiring 
payment to a third party upon; 

each use of said public key; 

each use of a user's private key; 
20 each certification of a certificate's status; and 

each confirm-to transaction by a user. 

7. A method as in any one of claims 1*5 wherein 
said rules include rules to pay for use by said 

25 recipient of intellectual property used in creating or 
operating the system. 

8. A method as in elaim 1 wherein said user 
transaction is invalid until said step of digital 

30 signing is performed. 



9. A method as in claim 1 further comprising the 
steps of: 
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in response to said signing by said recipient, 
said certifying authority accepting a transaction from 
said recipient, said transaction based on said user 
tr^fisaetion. 

5 

10. 2n a cryptographic system wherein a 
certifying authority issues digital certificates 
i^itifying users of said system, said digital 
certificates being digitally signed with a private key 

10 of said certifying authority to form a digital 

sigimtttre and requiring a public key of said certifying 
authority in order to verify said digital signature, 
ami %^erein a user transaction in said cryptographic 
aystmBi requires verification by a recipie^ of said 

15 \»er transaction, said verification based on 

information in said digital certificates and requiring 
said public key, a method of controlling access to said 
public key comprising the steps of: 

providing said recipient with a secure device 

20 containing an inactive form of said public key, wherein 
said public key cannot be obtained from said Mcure 
device; 

in response to a pr^etermined transaction with 
said secure device, activating said inactive pi;^lic key 

25 is said secure device, said predetermined transaction 
including information from the secure device 
identifying operational capabilities of the secure 
device and uniquely identifying said secure device and 
further including information uniquely binding said 

30 recipient to said predetermined transaction. 



11. In a cryptographic system wherein a 
certifying authority issues digital certificates 
identifying users of said system, said digital 
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certificates being digitally signed with a private key 
of said certifying authority to form a digital 
signature and requiring a public key of said certifying 
authority in order to verify said digital signature, 
5 and wherein a user transaction in said cryptographic 
system requires verification by a recipient of said 
user transaction, said verification based on 
information in said digital certificates and requiring 
said public key, a method of controlling access to said 

10 public key comprising the steps of: 

providing said recipient with a secure device; 
in response to a predetermined transaction with 
said secure device, transferring said public key to 
said secure device, said predetermined transaction 

15 including information from the secure device 

identifying operational capabilities of the secure 
device and uniquely identifying said secure device and 
further including information uniquely binding said 
recipient to said predetermined transaction, %rherein 

20 said public key cannot be obtained from said secure 
device. 

12. A method as in one of claims 10 and 11 
wherein said public key in said secure device becomes 
25 inactive after a predetermined time period, said* method 
further comprising the steps of: 

after said public key in said device becomes 
inactive, 

in response to another predetermined transaction 
30 with said seciire device, activating said inactive 
public key is said secure device, said other 
predetermined transaction including information from 
the secure device identifying operational capabilities 
of the secure device and further including information 
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unlquely binding said recipient to said other 
predetermined transafiti^. 

13. A neth^ of enf(^cinc| a policy in a 

5 cryptogra^ic crasmunieation system coa^rising the steps 
of: 

forming a digital message by a usor; 
e<»Bbining with said ii»ssage at least one user 

rule; 

xo forming a digital user signature based on said 

digital mess€ige, said at least one user rule and a 
private key of said user; 

ocnnbining said digital message, said at least one 
user rule and said digital user signature to form a 
15 digital user transaction; amS 

combining with said digital user transaction a 
digital identifying certificate issued by a certifying 
authority, said identifying certificate having a 
plurality of digital fields, at least one of said 
20 fields identifying said user, herein 

said at least one user rule specifying conditions 
under which said digital message trai»act|.on is valid. 

14. A metlwd as in claim 13, further coi^rising 
the step of: 

combining with said digital transaction a digital 
authorizing oartifioate, separate from said identifying 
certificate and issued by a sponsor of said user for 
authorizing transactions by said user. 

15. A method of enforcing a policy in a 
cryptographic communication system ccaqprising the steps 

of: 



25 



30 
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receiving a digital user transaction including a 
digital message, at least one user rule specifying 
conditions under which said transaction is valid and a 
digital user signature based on said digital message, 
5 said at least one user rule and on a private key of a 
user; 

receiving a digital identifying certificate issued 
by a certifying authority and having a plurality of 
digital fields, at least one of said fields identifying 
10 said user; 

verifying said transaction based on information in 
said certificate and in said at least one user rule; 
and 

accepting said transaction based on said outcome 
15 of said verifying. 

16. A method as in claim 15, further comprising 
the step of: 

receiving a digital authorizing certificate, 
20 separate from said identifying certificate and issued 
by a sponsor of said user and authorizing transactions 
by said user; and wherein said step of verifying 
includes the step of: 

verifying said transaction based on information in 
25 said authorizing certificate. 

17* A method as in any one of claims 13«-16 
wherein said at least one user rule includes at least 
one of: 

(a) allowed document types of said transaction; 

(b) allowed locations at which transactions can 
be formed; 

(c) allowed times at which transactions may be 
formed ; 
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(d) a time period within which said signature is 
valid; 

(e) a monetary limit for said transaction; and 

(f) co-signer requirements for said transaction. 
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KETHOO FOR SECURELY USING DIGITAL SIGNATURES 
IN A COHMERCIAL CRYPTOGRAPHIC SYSTQf 



BACKGRODW D QF THE INVENTION 

This invention relates to digital signatures. 
Jtore particularly, this invention relates to the use of 
digital signatures and certificates for digital 
5 signatures in a constercial cryptographic systea for 
enforcing security policies and authorization 
requirements in a manner that reduces risks to the 
users. 

Public-key cryptography is a modern computer 

10 security technology that can support the creation of 
paperless electronic document systems « providing that 
the user's digital signature on an electronic document, 
that is, the user's electronic authentication and 
verification of the electronic doctiment, can be given 

15 sufficient practical and legal meaning. Such paperless 
electronic document systems, or "docfflwnt 
architectures," will encompass not only trading 
partners operating tinder standard bilateral contracts 
but also global multilateral systems in which any 

20 entity can, in theory, correspond with any other entity 
in a legally provable manner, assuming that proper 
security controls are observed throughout. 

These systems will have enormous commercial 
significance because, in many cases, cost reductions on 

25 the order of lO-to-1 can be realised over current paper 
transaction procedures. This improvement is 
sufficiently dramatic such that many organizations 
would, for economic and competitive reasons, be 
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compelled to use them once their practicality had been 
demonstrated. 

No one disputes that paper is a bothersome 
anachronism in the electronic world or that verifying 
5 pen-and-ink signatures is costly and error-prone. At 

least with paper, however, the signer retains the basic 
**contextual controls** of document preparation and 
physical delivery. On a digitally signed electronic 
document, on the other hand, a signer controls only the 

10 encoded signature. All time, place and manner controls 
are absent, and nothing distinguishes a valid user 
signature from one fraudulently produced by another 
user who somehow obtained the first user's smart card 
and PIN. It would not take too many multi-million or 

15 multi^billion dollar losses to erase all the savings 
produced by this ** newfangled** office-automation 
technology* Therefore, digital signatures will see 
early use only in consumer **electronic coin purse** 
applications, where exposiire is low, and in wholesale 

20 financial transfers, as to which extremely tight 

security procedures are already the norm. However, 
these uses will have little general commercial impact. 

Thus far, major corporations and banks have 
declined to invest in these technologies due to lack of 

25 well-defined risk models and auditing standards and due 
to uncertainties regarding legal and liability issues. 
Serious investments to commercialize digital signatures 
will occur only after leading national auditing and 
legal experts have ruled that these systems contain 

30 adequate security controls to warrant reliance in 
mainstream intra- and inter-corporate business 
transactions, typically in the $10,000 to $10 million 
range. In order for this goal to be achieved, security 
controls must be formulated to reduce the risks of 
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participants in digital signature document systems to 
the ateolute lowest l^vel technically achievable. 

There are tvo types of cryptographic sys^ms in 
vhi<^ digital signet^Hres have been used: symmetric and 
5 asymmetric cr^tographic systen^. FKSURES 1(a) and 
1(b) illustrate the use of sysmetric and asymmetric 
algorithms for encryption. In sysmtetric (conventional) 
or^tograprhy, as shown in ncUMB 1(a), the s«ftder and 
recipient of a communication share a secret Icey 11. 

10 This key is used by ^e sendb^, the origii»t€dr of a 
comamni^tion, to ^^rypt the m^sage 12 and by ttie 
recipient of the co^Bounication to decrypt ^e message 
13. It may also be i»ed by tte recipi^t to 
authMitioate a message by having the sender use t^e 

15 secret key to o^ptrte some function sueti as a Ressage 
Au^entication C^e (KAC) baded upon tbe message; the 
recipient thus can be assured of the identity of the 
originator, because omly the sender and the recipient 
knov the secret key urod to cMqpute the KAC. DES is an 

20 example of a symmetric cryptographic system. 

In asymmetric (public key) cryp^ogr ai^y , shown in 
Tl&fMM 1 (b) , dlf fermt keys are \med to encrypt and 
decrypt a message, ^ch user is associated with a pair 
of ki^s. one key IS (the public key), is publioly khown 

25 and ie used to encrypt messages 17 destined for that 
ueer, and the other key 16 (the pri^te key) is known 
only to that user and is used to decrypt incoming 
messages 18. Since ^e public )»y need not be k^t 
secret, it is no longer necwssary to secretly convey a 

30 shared encryption key between c«Bmunicating parties 
prior to exchanging confidential traffic or 
authenticating messages. RSA is the most well-*known 
asymmetric algorithm. 
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A digital signature, however, is a block of data 
appended to a message data unit, and allows the 
recipient to prove the origin of the message data unit 
and to protect it against forgery. Some asymmetric 
5 algorithms (for example, RSA) can also provide 

authentication and non-repudiation through use of 
digital signatures* In order to sign data, the sender 
encrypts the data under his own private key. In order 
to validate the data, the recipient decrypts it with 

10 the sender's public key. If the message is 

successfully decrypted using the sender's public key, 
the message must originally have been encrypted by the 
sender, because the sender is the only entity that 
knows the corresponding private key. Using this method 

15 of signing documents, the encrypted message is bound to 
the signature, because the recipient cannot read the 
message without decrypting the signature data block. 
The signature-encrypted message can then be encrypted 
to the recipient using the recipient's public key, as 

20 usual. 

Digital signatures may also be formed using 
asymmetric encryption algorithms as described below and 
as illustrated in FIGURE 2. To sign a message, the 
message 20 is first digested (hashed) into a single 

25 block 22 using a one-way hash function 21. A one-way 
liash function has the property that, given the digest, 
it is computationally infeasible to construct any 
message that hashes to that value or to find two 
messages that hash to the sauiie digest. The digest 22 

30 is then encrypted with the user's private key 23, and 
the result 24 is appended to the encrypted or 
\mencrypted message as its signature 25. The recipient 
uses the sender's public key 26 to decrypt the 
signature 25 into the hash digest 22. The recipient 
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also digests (hashes) the message 20, which has been 
received either iinencrypted or encrypted and ttu^n 
decrypted by the recipient, into a blodc 27 usii^ the 
same one-way hesh function 21 used by the sender. The 
5 recipient then verifies 28 the sender's si^ature by 

chewing that the decrypted hash digest 22 is the same 
as the hashed message digest 27, 

Si^arating the signature from the message in this 
way, that is, not r^uiring the sender and recipient to 

10 encryi^ and decrypt the entire message in oir^r to 
verify the si^^ture, greatly reduces the amount of 
data to be eaicrypted. This is ii^mrtant because public 
Icey al^rithms are geiierally sub^antially slower than 
conventional algorithms, and processing the entire 

15 mssage in order to verify a signature %rould require a 
significant amount of time. The signature process also 
introduces redundancy into the m^sage, which, Imcause 
the mrasage wumt. hash to the specified digest, allo%rs 
the recipimt to detect xuiauthorized ^uinges to thm 

20 message. 

A digital signatture provides the seciurity services 
of (a) integrity, tecaiwe any modificatim of the data 
teing signed will rmmlt in a different digest and thus 
a different signattire; (b) origin Msthentication, 

25 beeause only t^ holder of the private key 

corresponding to the public key used for validation of 
the signature could have signed the mes€»ge; and (c) 
non*repudiation, as irrev^able proof to a third party 
that only the signer, and not the recipient or its 

30 en^loyees, could have created the signature. A 

synmetric secret' key authenticator, for example the 
X9.9 HAC, does not provide these services, since either 
of the two parties can create the authenticator using 
their shared key. 



wo 96/02993 



PCT/US95rt>9076 



Several of the mechanisms discussed herein assume 
the ability to attach multiple signatures or 
cosignatures to a document* A useful format for this 
purpose, as is veil known in the art, is defined in 
5 **PKCS #7: Cryptographic Message Syntax,"* RSA Data 

Security, Inc., 1993, which is hereby incorporated by 
reference. Each signature structure on a doctiment will 
contain an indication of the certificate needed to 
validate the signature along with a bit string 

10 containing the actual signature. Additionally, other 
infotlnation relevant to the particular signer may be 
included in an individual signature computation. This 
per-signer information may be included in the signature 
computation as "signature attributes.** 

15 In order for one user to identify another user for 

transmission of a message in a way that ensures the 
second user's possession of a private key, the first 
user must be able to obtain the other user's public key 
from a trusted source. As is well-known in the art, a 

20 framework for the use of public key certificates was 
defined in **X.509: The Directory: Authentication 
Framework,** CCITT, April, 1993 (**X.509*'), which is 
hereby incorporated by reference. These basic public 
key certificates bind a user's name to a public- key and 

25 are signed by a trusted issuer called a Certification 

Authority (OA). Besides containing the user's name and 
public key, the certificate also contains the issuing 
CA's name, a serial number and a validity period. 
Although X.509 does not impose any particular 

30 structure on the CAs, many implementations find it 

reasonable to impose a hierarchical structure in which 
each CA (in general) certifies only entities that are 
subordinate to it. Hence, we can construct a hierarchy 
of Cas, as shown in FIGURE 3, in which the higher level 
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CAS 31 (perhaps bank^) sign ^he car^ificatees 34 of th^ 
CAs 32 benea^ them (for exaotple, c<»q»anies) , and the 
lowest level of CAs 32 si^ user 33 certificates 35. 
At the top ot this hierarchy (not shoim) are a 
5 relatively few other root CAs, perh«^ one per omintry, 
that may **cros8*certify** each other's puitolic keys (root 
k^fs) . 

Various srcurity arcSiitecttires ^fine mi^hanisiiis 
to coT»truct a certification path throt^h tSm hierarchy 

10 to ^^ain a given user's certificate and all CA 
certificates necessary ^o \alidate it. ^tese 
ardhitectores share ttte common ^araeteristic tl»t a 
user need tr^Mt only oim oilier public tmy in or^er to 
c^i^in and valida^ any otl^r certificnte. %e trusted 

15 key may be that of the top-level CA (in a centralist 
trust model) or of the local CA tha^ issued the user's 
certificate (in a decentralized model) • 

Certificates also contain an oq^riration tete. If 
it is neeesMury to cancel a certificate prior to its 

20 expiration date, such as if the name associaticm 

becemes invalid or t^e corre^cmding private key is 
lost or compromised, the certificate may be to 
the CA's certificate revocation lis^ (CBL) or **bot 
list.** This list is signed by the CA and widely 

25 distaribut^d, possibly as ^irt of the CA's direcfeory 
entiry* The certificate remains on the <3UL until the 
certificate's eatpiration date^. 

Often certain infcnnutlon concerning an entity or 
CA needs to be made available in a trusted manner. In a 

30 secure X.500 Directory, this inforamtl<m M>uld be 

retrieved via standard Directory ^^ra^iorm and the 
result would be signed by the Direc^ry. In tha 
absence of such a secure X.500 iBqplMsentation, this 
information is placed in an attribute certificate. 
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which is signed by a CA in the same manner as the 
public key certificate. Attribute certificates would 
be created on presentation of the proper credentials by 
the user. For example, the user would present his 
5 public key certificate and prove he possesses the 
corresponding private key, as one form of 
identification. Attribute certificates are linked to 
the user's basic public key certificate by referencing 
the basic certificate's serial number and are revoked 

10 by an identical parallel CRL mechanism. Attribute 

certificates are discussed further in ''X9.30 Part 3: 
Certificate Kanagement for OSA,** ANSI X9F1, June, 1994, 
and U.S. Patents Nos. 4,868,877, 5,005,200 and 
5,214,702, which are all well-known in the art and are 

15 all hereby incorporated by reference. 

An attribute certificate is a structure separate 
from a public key certificate because proper separation 
of duties may often rec[uire that the CA that issues the 
attribute certificate be different than the CA that 

20 issues the public key certificate. A central CA might 
rarely of itself possess the req[uired security or 
authority to ""sign for" all of a user's authorizations. 
Having separate CAs generate various types of attribute 
certificates distributes risks more appropriately. Zn 

25 addition, the defined attributes may not be required 
*for all domains, networks or applications. The need 
for these attributes and for additional domain-specific 
attributes is determined by each domain. 

The user's basic public key certificate remains 

30 X.509 compatible, allowing its use with other 

applications and allowing use of commercial products 
for certificate generation. 

It is desirable to be able to construct a trusted 
organization that utilizes digital signature and 
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certificate mechaniss^ to enforce a security policy 
defined by rules within this organizational structure. 

It is also desirable to use digital signature and 
certificate mechanissM to enc^e industry-wide security 

5 policy and author izieit ion information into the 

signatures and certificates in order to permit the 
verifier of a signature to decide whether to aTO^t the 
signature or certificate as valid, thus accomodating 
and easing electronic commerce business transactions. 

0 It is fiurther desirable to reduce the risks 

Msociatad with digital si^^ture systmns, particularly 
with «id-*user smart cards, hy Gilding on this use of 
public key certificates and attribute certificates. 

It is farther desirable to prevent the use of such 

5 a digital siipciature system by Miy party that ai^t 

pur port to "accept** a transaction in contravention of 
the ai^licable authorization certificates when that 
party had not signed the applicable "system rules** 
agrenMnt pertaining to that system of communicating 

0 signer authorization. 

SIMMARY OF TME IHVEliTKMI 

Theee and other objects of the inveoitimi are 
aoooEB^liahed in accordance with the principles of the 

5 invention by providing a system for securely using 

digital signatiires in a commercial crypt^raphic system 
that allows industry-wide secwity policy and 
authorization information to be encoded into the 
signatiures and certificates by «&ploying attribute 

0 certificates to enforce policy and authorization 

requirements. In addition to value limits, cosignatiire 
r^uirements and document type restrictions that can be 
placed on transactions, an organization can enforce 
with respect to any transaction geographical and 
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temporal controls, age-of -signature limitations, pre- 
approved counterparty limitations and conf irm-^to 
requirements by using attribute certificates for the 
transacting user. Restrictions on distribution of 
5 certificates can be set using attribute certificates. 

Certificates can be used also to ensure key confinement 
and non-decryption requirements of smartcards in this 
system. 

10 BRTEF DESCRIPTION OF THE DRAWIMGS 

The above and other objects and advantages of the 
invention will be apparent upon consideration of the 
following detailed description, taken in conjunction 
with the accompanying drawings, in which the reference 
15 characters refer to like parts throughout and in which: 

FIGURES 1(a) and 1(b) show the prior art use of 
symmetric and asymmetric algorithms for encryption; 

FIGURE 2 is a flow chart illustrating the prior 
art process of a digital signature using an asymmetric 
20 encryption algorithm; 

FIGURE 3 shows a hierarchy of signature 
certification authorities; 

FIGURE 4 shows a directory information tree (OIT) ; 

FIGURE 5 shows an example of an authorization 
25 certificate; 

FIGURE 6 is a flow chart illustrating the prior 
art process of verifier enforcement of a transaction 
monetary value restriction; 

FIGURE 7 is a flow chart illustrating the prior 
30 art process of verifier enforcement of a transaction 
cosignature requirement; 

FIGURE 8 is a flow chart illustrating the process 
of verifier enforcement of a transaction document-type 
restriction; 
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FIGimE 9 is a flow chart Illustrating the process 
of verifier enforcement of a transaction geographical 
and temporal control; 

FIGURE 10 is a flow chart illustrating the process 
5 of verifier enforcement of a maximum age of render's 
signature restriction; 

FIGURE 11 is a flow chart illustrating the process 
of \^ifier and sponsor enforcement of a pre-af^roved 
counterp^ty restriction; 
10 FIGURE 12 is a flow chart illustrating the process 

of verifier enforcement of a transaction "confirm-to*' 
requirement; 

FIGURE 13 is a flow chart illustrating the process 
of a device ^s certification of key confinement and non^ 
15 decryption; 

FIGURE 14 is a flow chart illustrating the process 
of keeping public keys secret and enforcing signing of 
system rules; and 

FIGURE 15 is a flow chart illustrating the process 
20 of verifying user rules of a transaction » 

nCT^TT^ pgscRiPTiQtt OF THE imtmim 

nie following general principles and philosophies 
are refleotwl in the signature verification model 

25 defined in this invention. First, CA and user 

certificates can contain attributes that document the 
cmiditimis and assumptions under which they were 
created. Verifiers may siiqply reject all certificates 
and transactions that do not meet their minimum 

30 standards. 

Also, attribute certificates may be signed by a 
user's "sponsor* to signify that the sponsor's 
signature will be honored for official business if the 
transaction meets the requirements stated or implied by 
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the attributes. Although typically the user's sponsor 
will be the user's employer, the model can be extended 
to include the user's bank, credit card issuer, voting 
bureau, video rental store, public library or any other 
5 entity that might accept the user's signature. This 
sponsor (authorization) certificate is thus the 
electronic equivalent of an "affidavit of legal mark,** 
as used in the context of a traditional signature 
stamp. See Robert Jueneman, **Limiting the Liability of 
10 CAs and Individuals Regarding the Use of Digital 

Signatures,** presented to the ABA Section of Science 
and Technology Certification Authority Work Group, July 
2, 1993. 

Furthermore, industries may develop ** industry 

15 policy** statements that establish minimum requirements 
for signature verification. All participants would 
sign these multilateral agreements in order to ensure 
that all counterparties would be bound by the encoded 
restrictions. Normally, sponsor certificates should be 

20 required in all cases, and digital signatures would be 
deemed otherwise null and void in their absence. 
Industry-wide policies would also define (l) relevant 
document types and classes, (2) signer roles and 
titles, and (3) coded symbols for incorporating by 

25 reference standard contractual terms and conditions. 

Moreover, there must be strict adherence to the 
principle that all restrictions can be enforced in an 
entirely automated manner (that is, verification **on 
sight**) , without reference to paper agreements or human 

30 interpretation, sometimes also termed **fully 

machineable straight- through processing.** In complex 
and/or high-volume environments, this is required in 
order to give these security controls credibility in 
the eyes of audit and legal experts. Reference to 
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trusted ^ird parties should also be miniaized to 
reduce verification latency times. 

miile these restrictions seem complex, they merely 
reflect ordinary business procedures made explicit for 
5 purposes of machine verification. Formerly, euch 

^ntrols WBTB enforced inside the sponsor's ccadsputer 
systems tefore sending out the transaction* Homver, 
vith the advent of multilateral distrlhuted 
transactions, the verifying user. is typically off-line 

10 frOTi the sender's sponsor's system, and so the verifier 
raist enforce the sponsor's auttusrization model, as 
reflected in the attriirate certificates. Once this 
methodology is speieified, office software vendors will 
devel^ meira-driven syBtems create and manage user 

15 atteibutM, ami the cost to user organizations will be 
relatively low. 

QCTMiizational St ructure In Certificates 

The eertif ioates th««selves may reflect the 

20 structure of a sponsor organization. IMicause many 
authorization decisions are iMMd on tlie tiser's 
p^ition in an orgamization, tfae mrganizationaX 
structure and the user's posit i^ therein may be 
fl^eeifiml as part of a user's name. .Hames in 

25 »»tifioatM are specified in terms of the X.5O0 
Dimtory Bi^tal, as follows. 

^e X.500 Directory str^u^iure is hierarchioal; the 
resulting distrilmted database c«q)rises the Directory 
Information Tree (DZT) , as shown in FZOURE 4. Bach 

30 entry 41 is of a specific object class and consists of 
a set of properties <»lled attributes 42. An attribute 
42 consists of a tyiM 43 and one or more values 44. 
'nius, in an entry of class organization, one attribute 
is the organizationMame; in an entry of class 
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organizatlonalPerson, attributes might include title 
and telephoneNumber • 

Each entry also has one or more special attribute 
values used to construct the object's name; this 
5 attribute value is the relative distinguished name 
(RDN) of the entry » An object's distinguished name 
(DN) 45, which is created by concatenating the relative 
distinguished names 46 of all entries from the DIT root 
to the entry, uniquely identifies the object in the 

10 global DIT* 

Several of the attributes defined in X.500 may be 
usefully included in the user's attribute certificate. 
For example, the object class can be used to 
distinguish between entities (for example users and 

15 roles) whose distinguished names are of the same form. 
Also, the title may be used in making authorization 
decisions. 

In addition to the use of the OIT to group 
entities along organizational lines, X.500 defines 

20 several object classes that can be used to construct 
arbitrary groups of entities • These object classes 
include the organizational role, whose **role occupant** 
attribute lists the names of the users who occupy the 
role, and the group of names, whose '^member" attribute 

25 lists the names of group members. To convey this 

information in a trusted way, one could define role and 
group certificates that convey the names of the role 
occupants or group members, respectively, and that are 
signed by a CA, thus enabling use of this feature 

30 outside the context of an X.500 directory system. 

Group and role certificates may be used in 
conjunction with a cosignature mechanism to simplify 
the construction of cosignature requirements. For 
example, a transaction might require the signatures of 
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three occupanirs of fche **purchasing agent^ role. A user 
may also indicate the role in which he is acting by 
including the role in the signature computation as a 
(per-signer) signature attribute. The asserted role 
5 may then be matched against a role certificate (or the 
xxser's attribute certificate) during verification. 

PQiigy Information in Certificates 

It is another embodiment of this invention to 

10 encode infomation regardir^ a CA's security policy 
into the attribute certificates of the CA and its 
stibscribers, so that the verifier of a signature can 
use information in determinii^ irtiether to accept a 
signature as valid. In general, the CA's certificate 

15 will convey the rules tha^ a CA uses when maJcing 

certification decisions, %^ile the user's certificate 
will convey the information used by ^e CA when 
applying these rules. 

Attributes in CA certificates can indicate 

20 security policy and assurance information for a 

particular CA. This policy information can also be 
ii^erited by subordinate CAs, allowii^r aasy 
construction of security domains sharing a comaon 
policy. Policy attributes in a CA's certificate might, 

25 ascmg others, include: 

(1) Liability Limitations: the extent to %mich a 
CA is liable in the event of various probl«w (for 
example, CA key cOTipromise, defective binding) ; this 
might be no liability, full liability or a specific 

30 monetary amount. 

(2) Trust Specification: a description of which 
users ami CAs a given CA can certify, expressed 
relative to the CA itself (for example, ••all 
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subordlnates**) , or to the OIT in general (for example, 
**the subtree below Organization ABC**) , or to others. 

(3) Required Attributes: a list of those 
attributes in the user^s attribute certificates that 
nust^ be yeri^ied against a transaction and/or ^ts 
context in order for the transaction to be considered 
authorized. These attributes would be found in the 
certificate (s) of the sponsor and allow a single 
authorization certificate to contain authorization 

10 attributes for use with multiple applications* Some 
suggested user authorization attributes are defined 
later. 

(4) Allowable Name Forms: a specification of the 
allowable name forms that the CA may certify* This 

15 information is held as (a) a set of name bindings, 

which defines the attributes that may be used to name 
entries of a given object class (that is, the allowable 
RON formats for entries of that class) , and (b) a set 
of structure rules, which defines which object classes 

20 may be adjacent (that is superior or subordinate) to 
each other in the DIT, that is, the order in which 
object classes may be chained together to form a 
complete DN. This policy attribute may be used to 
restrict the type of entities that may sign 

25 transactions. For example, for wire transfer 

'applications, it might be desirable to restrict 
signature capability to the organization itself, rather 
than to users within the organization, since this is 
similar to the current mode of operation using DES 

30 MACS* 

(5) Cross-Certificates: it may be desirable from 
an efficiency point of view to allow certifying 
entities and as organizations to cross-certify each 
other in order to constrain the length of certification 



wo 96702993 



PCT/US95/09076 



-17- 

paths. On the other hand, it is not desirable to allow 
certification paths to contain arbitrary numbers of 
cross certificates, as it is difficult to determine the 
level of trust in the entity at the other end. Many 
5 certification architectures restrict certification 
paths to contain only one cross-certificate. To 
accommodate a wider range of policies, an attribute may 
be added to the attribute certificate associated with 
the cross-certificate indicating .that the cross- 
10 certifier explicitly allows the use of 

cross-certificates issued by the OA being cross- 
certified • 

Attributes in a user's or entity's attribute 
certificate may represent the information verified by 

15 the CA when creating the certificate for the entity. 

Policy attributes in a user's certificate might, among 
others , inc lude : 

(1) Binding Information: the criteria used to 
bind the public key to the identity of the entity being 

20 certified. This includes (a) the method of delivery, 

such as being presented in person, by authorized agent, 
by mail or by another method; (b) the method of 
identification, such as by reasonable commercial 
practices, verified by trusted third party, dual 

25 control, fingerprint check, full background 

investigation or another method; (c) the identification 
documents presented to the CA; and (d) the subject's 
entity type, that is, individual, corporation, device 
or other. 

30 (2) Trusted Third Parties: the names of any 

txiisted third parties or agents involved in the binding 
process . 

(3) Roles: it may be useful for authorization 
purposes to indicate which roles (both internal and 
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extemal to the organization) a user may exercise. 
This is in ccmtrast to a role certificate, which vould 
be issued to the role and contain the names of all 
occupants . 

5 (4) Relative Identity: a CA may wish to certify 

only a portion of the mt of an individual. In 
^^ticular, the CA might disclaim liability for 
correctness of an individual's personal name, since, 
ui^er legal A^ncy principles, the individual's 
10 signature is birring on their organizational sponsor in 
any event, ^x^ider the name; 

C«US; 0»Bankers Trust; OU»Global Electronic 
CoaiEMrce; ^>:^ank S^ia; TI^VP 
"^e CA might certify ^ly the validity of the 
15 orgutizatiOT, organiza^iomil unit and title portions of 
the individual's distinguished name, all of t^iich are 
easy to verify, %ihile the personal naiM would only be 
''reasonably believed accurate •** In vie^ of the 
relative ease of obtainiiug false identity papers, this 
20 avoids the need for prohibitively expensive background 
investi^^ions. Such an identification can be relied 
on in an ordinary coaaneroial setting but not in a 
proceeding concerning a will or inheritance, for 
example* 

25 (9) Absolute Idmtity: ve define relative 

identity as the user's identity "relative** to his 
organizaticmal sponsor. Put another way, ve certify 
all el«ftents of the user's "business card identity," 
except his personal name. As a special case, som CAs 

30 might undertake to certify the absolute identity of 
selected users, say the children of wealthy clients, 
diplraats or national security operatives, almost 
certainly bolstered with biometric technicpies. This 
would be rare and is presented here only for 
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completeness in order to round out the **relatlve 
identity'^ concept. 

Authorizati on Information in Certificates 
5 Attributes may convey restrictions that control 

the conditions under which a signature is valid. 
Without such restrictions, the risk of forgery would be 
considered excessive, since an electronic signature can 
be affixed to almost any digital docximent by anyone 
10 possessing the user's smart card and personal 

identification number (PIH) . In the electronic 
environment, the normal contextual controls of document 
creation and physical delivery are either weak or 
nonexistent. 

15 Even authentic users are hardly trustworthy to 

undertake free-form offline commitments, and 
organizations will thus welcome the capability to 
positively restrict the scope of express signature 
authorization. Such authorization attributes might, in 

20 addition to standard X.300 attributes, include 

Transaction Limits, Cosignature Requirements, Docximent 
Types, subject matter restrictions. Authorized 
signatories. Geographical and Temporal Controls, Age of 
Signature, Pre-approved Cotinterparties, Delegation * 

25 Controls, and Confirm^^To Reqpiirement. These attributes 
can be encoded in one or more authorization 
certificates signed by the signer's organizational 
sponsor or by an external CA acting on behalf of the 
organization. An example of an authorization 

30 certificate and an associated transaction is shown in 
FIGURE 5. 

When a recipient user (verifier) receives a 
transaction 51 from a sending user, the recipient first 
uses the sender's basic key certificate 55 to verify 
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the sender's signature 52 on the transaction 51. As 
vill be described in greater detail below, the 
recipient also uses the sender's authorization 
certificate 56, signed by the sender's sponsor 59, to 
5 verify tbe cosignatures 53 and timestamp notarization 
54 appended to the transaction 51 and to verify that 
the attribute values 57 of the transaction 51 fall 
within the authorized attribute values 58 as specified 
in the authorization certificate .56. 

10 ^e user may be subject to transaction limits that 

control the value of transactions or other documents 
that the user may initiate. The user's signature will 
be vaXid mly on transactions originated either to a 
certain monetary limit or between two m<metary value 

15 bmii^laries« Accordingly, as sho%m in FIGURB 6, the 

sending user sends a transaction 601 signed 603 by the 
sender (actually by the user's smart card 600 
containing his private key) and appends thereto an 
authorisation certificate 604. The verifier uses the 

20 authorization certificate 604 to verify 607 the user's 
sicpnature 603 and to verify ^at the transaction 
monkery value 602 falls within the transaction limit 
attribute value 605 in the authorization ccurtif ioate 
604* The verifier also verifies 609 the sensor 

25 signature 606 on the authorization certificate 604 

*using the sponsor's ^iblic key 610* If any of these 
si^Mtures and attribute values does not verify ir the 
transaction is rejected 611. Zf verification is 
complete, the transaction is accepted 612. 

30 With regard to cosignature requirements, 

additional signatures may be required in order for a 
given signature to be considered valid. Quorum and 
weighting mechanisms can be used to construct fairly 
elaborate checks and balances for explicitly governing 
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the level of trust in each user. The particular 
sequence or order of required signatures may also be 
specified* Referring to FIGURE 1 , sending user A sends 
a transaction 702 signed 703 by his own smartcard 700 
5 and, if user B's coisignature is required on the 

transaction 702, signed 704 by the smartcard of user B 
701. Sending user A also appends his own authorization 
certificate 705 to the transaction 702. The verifier 
uses the authorization certificate 705 to verify 711 

10 user A's signature 703, and uses the sponsor's public 
key 713 to verify 712 the sponsor's signature 707 on 
the authorization certificate 705; if either signature 
does not verify, the transaction is rejected 720. If a 
cosignature value 706 is required 714 by the 

15 authorization certificate 705, the recipient enforces 
the requirement by verifying 715 cosigner user B's 
signature 704 on the transaction 702, and then checks 
cosigner user B's public key certificate 708 by 
verifying 716 the signature 709 of the certificate 

20 issuer, using the issuer's public key 717. If the 

signat\xre of either user B or his certificate's issuer 
does not verify, the transaction is rejected 722. 

The use of cosignatures allows an organization to 
effectively define checks and balances, and to 

25 explicitly specify the level of trust in a user. The 

use of cosignatures also greatly reduces the risks that 
result from inadvertent compromise of a private key due 
to theft, misuse or misplacement of a smartcard or PIN. 
In particular, it is believed that the ability to 

30 require cosignatures, value limits and related controls 
will enable organizations to carefully manage and fine- 
tiine all signature authorizations, thereby giving them 
all the tools needed to manage and limit their risks. 
Use of cosignatures further allows distribution of the 
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authorization function over multiple locations and 
hardware platforms, with the resultant minimisation of 
risks that might result from aceess control failures on 
one of those platforms. See U.S* Patents Kos. 
4,868,877, 5,O0S,2«0 and 5,214,702. 

Author i sat iofi signatures, wtiich must meet ^e 
restriotionm sf^cified in the signer's certificate, can 
also be distinguished from other oosignatures by 
including the signatura purpose as a signature 
attril^te ami by rei^iiring that an indication ot the 
signature purpose be inoluiSted in tte data being signed, 
^niis sigf«iture*^purpose attribute might require the 
values of: (a) an authorisation signature eqp|^<^riate 
to the document, (b) an authorisation cosignature 
a^r^riate to the docuamnt, %fhere the cosigner's 
certificate has sufficient authority to authorise the 
document, and (c) a vitness cosignature, where the 
cosigner's certificate does not by itself have 
sufficient authority to authorise the document, 
signature purpose encodings discussed in draft AHSI 
standard XI2.58 Version 2 (Appendix) issued by the Data 
Interchange Standards Association (DZSA) , which is 
%rell«lcnown in the art and is hereby incorporated by 
reference. 

Ae user can also be restricted to signing only 
particular document types, such as ordinary 
corres po ndence , pur^ase orders, specified BDI 
transaction types, business contracts, specified 
financial instruments, etc., as defined by 
industry-wide policies. It may also be desirable for 
efficiency to exclude certain large classes of 
transactions and documents. Referring to FIGURE 8, the 
recipient enforces the document-type restriction in the 
sender's transaction 801 by first verifying 807 the 
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sender's signature 803 on the transaction and by then 
verifying 808 the document type attribute value 802 
within the transaction 801 to enforce the document type 
restriction 805 within the sender's authorization 
5 certificate 804. The recipient then verifies the 

authorization certificate 804 by using the sponsor's 
public key 811 to verify 809 the sponsor fs signature 
806. If either a signature or the attribute 
restriction does not verify, the transaction is 

10 rejected 810, 

It is also desirable to add positive or negative 
restrictions pertaining to transaction subject matter 
or context class. For example, to restrict an agent to 
signing purchase orders for some class of goods (such 

15 as, for example, office supplies) , or to deny authority 
as, for example, in the case of denying an agent the 
ability to piurchase pornographic materials. Subject 
matter restrictions are enforced by the transaction 
recipient in the same manner as doctiment type 

20 restrictions, and may be implicit in many document 
types, yet requiring separate specification for the 
more generic document types. 

An organization can indicate that there are 
specific authorized signatories, that is, that only. 

25 specific individuals can ''sign for" the organization, 
similar to a standard "corporate resolution" to this 
effect. This might complement the document-type 
concept, as an additional control on signing of 
"corporate" document-types. This restriction can be 

30 implemented by specifying that a cosignature is 

required in which the cosigner's title (in its 
distinguished name) must be equal to one on a specified 
list contained in a authorization certificate. This is 
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in lieu of naming a list of one or more required 
cosigners. 

Geographical and t antral controls iiiclude 
locations and tiii» periods from which ^tr ^^ggtjLjg|g^ 
5 considered valid. Use of a local trusted ^timestamp 
notary" is assusied* Such a notary «rould append a 
trusted timestn^ to the originator ^s signature on a 
docximent and would then sign the result. Thus, 
time-of-day and day-of-week restrictions would normally 
10 coincide with the work-week of the user's locale « 

Also, location information would be associated with the 
notary so as to restrict access to a specific network 
^^ment, typically the user's assigned %rork area. The 
■•granularity" of location controls wmild d^pei^ on the 
15 network architecture. The signer or the sigqr»r's 

cOTiputer system must attach a certified timestas^ from 
a specified local serwr to the transaction, or else 
the verifier cannot accept the transaction and 
signer's spommr will not be bound by it. As shorn in 
20 FIGURE 9, tifee sending user attaches to the transaction 
901 an authorisation certificate 902, as usual, an 
authorized timestamp 903 and a time server certificate 
904. The recipient verifies 921 the sender's signature 
905 «i the transacti«i 901 and v^if ies 922 ttee 
25 ^mtsmr's si^iature 90S on the authorisation 

certificate 902. The recipient then (I) verifies 923 
that the timMtamp transaction text hash 909 Mtches 
the result of the text of the transaction 901 hashed 
with a known hash function, (2) verifies 924 that the 
30 time and date 910 on the transaction timestanq? 903 fall 
within the authorized time and date 906 attribute 
values as specified in the authorization certificate 
902, (3) verifies 925 the time server signature 911 on 
the timestamp 903, and (4) verifies 926 the sponsor's 
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signature 912 on the time server certificate* If all 
these conditions are satisfied^ the transaction is 
accepted 931; if not, the transaction is rejected 930. 

5 Furthermore, a document may not be valid unless 

the signature is verified within some specified time 
period. For high-value transactions this age-of- 
signature attribute period would be quite short, while 
for more normal transactions, especially those sent via 

10 s t or e-and- forward systems such as X.400, a longer 

interval (such as two days) would be appropriate. 
FIGURE 10 shows enforcement by a recipient of the age- 
of -signature attribute value. The time of verification 
would be provided using a receipt 103 signed by a 

15 trusted timestamp service 104 containing, at a minimum, 
the recipient's name and the signature from the 
original transaction. The verifier must submit a 
timestamped copy of the original signature that is 
dated promptly after the time and date of the original 

20 transaction, or else the sponsor will reject it. As 
shown in FIGURE 10, the recipient (verifier) verifies 
121 the sender's signature 107 on the transaction 101 
and verifies the sponsor's signatiire 115 on the 
authorization certificate 102. The recipient then * 

25 verifies 122 that the difference between the date 105 
and time 106 on the transaction 101 and the date 111 
and time 112 on the timestai^) 103 is within the age-of- 
signature attribute restriction 108 in the 
authorization certificate 102. The recipient also 

30 verifies 123 that the hash 110 of the transaction 101 
within the trusted timestamp 103 matches the text of 
the transaction 101. If all these conditions are 
satisfied, the transaction is accepted 130; if not, the 
transaction is rejected 131. 
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A similar concept is that of a mininuiD age of a 
signature. In this case the signature would not be 
valid until some minimtim time after it had been signed* 
This allows for a smartcard to be reported lost and for 
5 a revocation notice to be broadcast to the recipient. 
Th0 control attribute can specify a loaximum and/or 
minimum age for the signature . • • 

A ■*pre*approved counterparties** attriteta value 
restricts an entity to dealing only with some specified 
10 set of Icnown trustworthy partners. This is a oramon 
requirement in dial-up home baTiking syst«i^, iirtiich 
t^ically require that all authorized payees be 
speci£i«l in advance. Another %ray at statiisg this is 
that ** free-form transfers** are forbidden* Spmisors 
15 realise that, in case of an error, they stand a better 
chance of succerafully reversif^ the er»>r when dealing 
with a large, solvent and creditworthy party than when 
dealing with a si&all, unknown and unauthorised one. 
Separate certificates can be issued for raeh 
20 counterparty in order to |«revent a cooipetitor from 

obtaining the user's customer list (other than himself) 
in a single certificate. The am>^ov«l emmterparty can 
be coded either as a common name, a distinguished name, 
a certificate nund^er, or the hash value of eil^ier the 
25 .distinguished name or the counterparty's public key. 

In order to claim the benefit of the transaction, the 
verifier mist sutailt a certificate that matches the 
encoded coxinterparty value. 

FIGURE 11 shows verification by the user's sponsor 
30 of the user's transaction after receipt by a recipient. 
The recipient (counterparty) verifies 1110 the user's 
signature 1103 on the transaction llOl and verifies 
nil the sponsor's signature 1105 on the user 
authorization certificate 1102. If either of these 
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signa'tures does not verify, the transaction 1101 is 
rejected 1112 • If the signatures verify and the 
transaction is accepted 1113 by the recipient « the 
recipient endorses the transaction lioi by issuing his 
5 verified transaction 1114 counter-signing 1116 the text 
1106 of the original user transaction 1101 and the 
sending user's signature 1103, vith the recipient's 
certificate 1115 attached. In enforcing the pre- 
approved counterparty restriction in the sending user's 

10 authorization certificate 1102, the sending user's 
sponsor verifies 1121 the sending user's signature 
1103, as included in the recipient's verified 
transaction 1114, and verifies 1122 the recipient's 
signature 1116 thereon. If these signatures are 

15 verified, the sponsor next verifies 1123 the 

counterparty public key hash value by hashing the 
recipient's public key 1117 and checking the result 
against one of the authorized counterparty public key 
hash values 1104 as specified in the user's 

20 authorization certificate 1102 (the recipient's public 
key 1117 that the sponsor hashes for verification is 
itself verified 1124 when the sponsor verifies the 
recipient's certificate). If these conditions are met, 
the transaction is accepted 1125. 

25 The attribute values of delegation controls can 

liail: the types and value ranges of authorizations that 
a CA nay specify when issuing- an attribute certificate. 
They can also serve to limit the scope and depth to 
which a user may delegate his signing authority to 

30 others. For example, a root CA might limit an 

organizational CA to issuing authorizations only to 
allow its end users to sign doc\iments whose dociiment 
types fall into a range of docvunents related to state 
tax administration- Or a CA might grant some authority 
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to a user vith ibbe provision that it can be delegated 
only to another person with the rank of assistant 
treasurer or higher, for a time not to exceed thirty 
days, and without the right to further subdelegate. 
5 Another author iMt ion attribut:e, call^ a 

**confira^to requirement** value, prevents the si^iature 
from teing valid unless the verifier sends a copy of 
^e verified transaction to a third |Mrty, typically 
the iMer's organisational sponsoir or work supervisor, 

10 at a specified mail or network address, aund either (a) 
revives an aooept/rej^t message, or (b) a s^cified 
time el^^es» This re<^ir«itent is similar to a 
cosignature but occurs after the transaction is Mnt 
ratlMT than fe^fore. Su^ af^r^the-fact oonfinmtion 

IS could be acMptable in lower risk situations in which 
£sw transactions would be rejected and in which 
obteinii^ the cosignature of the third party in advance 
may be unduly burdensome. Or it might be preferred in 
high-value cases where positive on-line checking is 

20 demanded. In ttwt case, the flow pattern reverts back 
to an on-line rather than an off-line sys^tem* As shown 
in F:unmE 12, the recipient first, as usual, verifies 
1211 the seidder's signature 1203 on the transaction 
1201 and verifies 1212 the sponsor's signature- 1205 on 

25 the UMo: authorisation certificate 1202; if either of 
* these si^Mtures does not verify the transaction 1201 
is rejeoted 1213. If the signatures are verified, the 
recipient sends 1214 a confirmation message consisting 
of the original transaction 1201 (the transaction text 

30 1202 and the sending user's signature 1203) to the 

user's sponsor 1215, as specified 1204 in the sender's 
authorisation certificate 1202. nie recipient should 
receive from the sponsor 1215 the same message in 
return as confirmation 1216, but signed 1205 by the 
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sponsor. The recipient then verifies 1217 the 
sponsor's signature 1220 and the confirmation n^ssage 
1216, and accepts 1219 the transaction 1201. 

In order to create coaqplex combinations of 
5 restrictions, a filter expression, which is a Boolean 

or logical expression involving one or more attributes, 
can allow construction of restrictions involving 
multiple attrilEmtes. The attribute assertions are 
linked with the usual Boolean connectives: ''ai^**, **or" 

10 ami "not". For exaiq^le, the sponsor might restrict a 
user to sxibo&itting transaction with a type egual to 
"purchase order " and a value less than $100, 0O0> 
Assertions may involve either a single attrilrate value 
(equality, less than, greatenr than, etc. ) / »2^^ipl*^ 

15 ^^lues of an attribute (subset, superset, etcOr or the 
presence or absence of an attribute in the doctnrant. 
Of course it will be appreciated that any or any of the 
described restrictions, as %rell as others, can be in 
effect at the same time for the same document or 

20 transaction. Th€»e restrictions have been discussed 
and illustrated separately for clarity. 

The use of authorization attributes allows a 
recipient to verify authorization as %rell as 
authentication. In such a scenario, the sponsor 

25 c^tifiMtes, anchored by the sponsoring organization's 
certificate, irould be interpreted as authorizing "on 
si^t" the transaction to v/hidh they are applied, 
assuming all specified restrictions are met. 

A set of basic policies mtist be defined for use 

30 throughout the financial services industry and other 
ind\istries in order to provide a well-defined, 
predictable level of service for the verification 
process. These policies would be agreed to on a 
multilateral basis by every participating firm and 
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could Stipulate that certain of the restrictions and 
authorizations discussed in this section would always 
be deemed to be in effect unless expressly provided 
otherwise. One of the more important elements of these 
5 industry agreements would be the definition and coding 

of document types. This must be done on a per-industry 
basis, since the rules will obviously be much 
different, for instance, for customs inspectors, 
aircraft inspectors, auditors, tax officials, etc. 

10 Certain authorization attributes may pertain to 

the specific content of the document itself. This can 
pose problems for automated machine verification, 
because the verifier's computer may not always be able 
to determine the values of such attributes for a given 

15 document or trauisaction. Exaua&ples include monetary 
transaction limits, dociiment types, and security or 
confidentiality labels. Therefore, it is desirable to 
provide a standard data block, preferably at the start 
of the document or the transaction, clearly encoding 

20 the attribute, for example the stated monetary 
transaction value, document type or security 
sensitivity label. This document tag will be appended 
by the signer's computer for the convenience of the 
verifier and a^ an aid to the verification process. 

25 However, in the event of a conflict between the tag and 
*the actual content of the document, the language of the 
document would be controlling. In the case of 
structured transactions, such as EDI transactions, in 
which the document types and monetary values are 

30 already completely machine readable, document tags 
would not be needed. 

As a possible convenience in processing simple 
authorizations, especially where a given user signs 
many similar transactions, it may often be helpful to 
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copy thB user's public key out of his basic 
authentication certificate and include it as another 
attribute in an authorization certificate. This 
permits the authorization certificate to serve both 
5 purposes (authentication and authorization) and allovs 
the sender to omit the basic authentication certificate 
from each transaction. In addition, where a device is 
bein9 relied upon to fulfill a given comlition, it may 
lUcevise ^ advantageous to copy the user's device 
10 public key into the authentication or authorization 
certificate as veil, further eliminating the need to 
send the device certificate with each transaction. 

Third F&rtv Interactions 

15 Additional, useful features of digital signatures, 

beyond those that can be provided iising attribute 
certificates, involve interaction between a signer and 
third parties of various types. 

One such use for digital signatures is electronic 

20 notarization. As discussed above, there will be a need 
to cosign documents using a third party that is trusted 
to provi^to an accurate timestamp ai^/or locati<m 
infonution. Simply relying uj^n signature originators 
to provide t^is information in an accurate fashion 

25 leaves signatures vulnerable to fraud based on, for 
exaa^lej pre*- or |H>8t*<lating of documents. An 
electronic '^notary*' wuld be trusted by virtue of its 
CA's policies to provide this information corrMtly. 
The multiple signature capabilities already assumed can 
^30 be expai^ed to provide a framework for this service. 

For notarization purposes, timestaxB^s and location 
. information will be included as signature attributes. 

Individual signature structures may either be detach^ 
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and scored or, if desired, conveyed separately from the 
document. 

Multiple signatures or joint signatures on the 
document itself can also be distinguished from 
5 ** countersignatures, " which are signatures on the 

signature structure in which they are found and not on 
the document itself. A countersignature thus provides 
proof of the order in which signatures were applied. 
Because a countersignature is itself a signatiire 

10 structure, it may itself contain countersignatures; 

this allows construction of arbitrarily long chains of 
countersignatures. Electronic notarization would then 
consist of countersigning the originator's signature 
and including a timestamp within the information being 

15 signed. For very high-risk applications it may also be 

desirable to require multiple signatures on each 
certificate by one or more CAs, with the signatures 
being performed in independent cryptographic facilities 
and with different private keys. 

20 Various levels of service can be defined for 

electronic notaries based on the level of data 
verification performed prior to signing (ranging from 
mere existence of the document, in which case 
notarization may be completely automatic, to huAan 

25 verification of document content) and based on data 

retention and audit capabilities. 

Another use for digital signatures is for 
delegation or "power of attorney" certificates. 
Because users are often tempted to entrust their 

30 devices or smartcards to others, for example, 

secretaries or co-workers, when the users go on 
vacation, the frequent situation, in which one user 
obtains another user's smartcard and PIN, exposes the 
smartcard to possible misuse. The system therefore 



PCT/US95/09076 



-33- 

facilitates the issuance of power of attorney 
certificates that allow a delegate to associate the 
signature of his own snartcard with the authority of 
the delegating user, the power of attorney certificate 
5 %r<mld include at a miniausi the name of the de legator, 

identification of the delegate's public key certificate 
af^ a short validity period, and would be signed by the 
delegator. Another possibility is for the delegate to 
CTMte a new key pair exclusively for use with the 

10 delegator's signature, with the new public key included 
in the power of attorney certificate. This %rould 
eliminate any potential confusion between use of the 
delegate's private key on behalf of the delegator and 
on his own b^alf . 

15 llie problem of handing over smar^ cards can be 

greatly reduced by providing a workable alternative 
t^at preserves the principle of individual 
accountability. Wide implementation of this feature 
will make practical the disallowancei of smartcard 

20 loans, a highly desirable goal. 

TtkB use of delegation certificates discussed above 
ia^lies that the us^r is acting as a CA. Zn ^cmm 
cases, particularly those in which the transaction 
orosses organizational boundaries, there may be concern 

25 that ttoe level of controls and auditing available with 
the individiuil user's cryptograf^ic device (for 
exaoqple, a smart card) is not sufficient. Zn such 
cases, delegation certificates could be issuckl by a CA 
upon request of the delcigator as normal authorization 

30 certificates. This also allows the delegation 

certificates to be reveled using the standard CRL 
mechanism. Users' certificates might then indicate a 
list of possible delegates, and the delegation 
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certlficate itself would contain an attribute naming 
the de legator* 

In exercising the power of attorney, a user may 
indicate that he is signing for another user by 
5 including in the document or transaction a 

"signing-for" signature attribute, that is, the name of 
the user being signed for. There must be a valid 
delegation certificate authorizing the signer to act 
for the user being signed for. Delegation is also 

10 useful in connection with a cryptographic module in a 
user's personal computer. Hashing and signing a 
document should ideally be a unitary operation in order 
to prevent sxibstitution of a false hash via software 
hacking. However, the typical smartcard lacks the 

15 computing power to hash a very long document. One 

solution is to let the smartcard delegate this function 
to the cryptographic module using a very short-lived 
delegation certificate valid for only a few minutes. 
This certificate is signed by the user's smart card and 

20 indicates that the user of the smart card has allowed 
the delegation. See, for example: Gasser, M. , A. 
Goldstein, C. Kaufman and B. Lampson, **The Digital 
Distributed System Security Architecture,** Proceedings 
of the 12th National Computer Security Conference, 

25 1989; Gasser, M. and E. NcOermott, *'An Architecture for 
* Practical Delegation in a Distributed System,** 
Proceedings of the 1990 IEEE Symposium on Security and 
Privacy. 

30 WQn-Pttblig Public Kav 

A more basic problem, however, is ensuring that 
all possible recipients will actually employ the 
certificate- and attribute-verification methods 
described above. Although these methods allow 
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sponsoring organisations to protect th«&selves, their 
users amd those with vhom they transact from liability 
based upon falsified transactions by allowing them to 
verify the identity and qualifications of those with 
5 vh«& they irransact and t^ie ^aracteristics of the 
transactions prior to t:ransacting, ^ere is no 
guarantee that all recipients will actually so verify. 
If a recipient acts upon a transaction without first 
verifying the attributes of both- the sender and ^e 

10 transaction, ami if the sender is later fmind to have 
sent a fraudulent or unauthorized transaction, the 
recipient could then claim liability fro^ the sender or 
its sponsor by claimlifig that l^e recipient was unaware 
of any requirement for authorization verification of 

15 the user's basic signatulre. One way to ensure that 
sponsors and other entities are protected from 
liability in such a situation is to require that the 
signer include the hash value of each of his identity 
and authority certificates as attributes within his 

20 signature. This can prevent a verifier from claiming 
that he was unaware of such certificates and ot the 
restrictions they impose. However, the signer might 
(intentionally or unintentionally) omit to do this* 
Another morm ea^atic way to ensure verifier cos^liance 

25 is to prev«rit the root key, the public key of ^e 
ultimate authority, that is, the highest* level 
certify if^ authority. Which key would-be verifiers will 
need in order to verify any part of a transaction, from 
being distributed to a user (or to the xiser's device or 

30 smartcard) unless the user contracts with the 

cryptographic system and agrees to verify all parties 
and all transactions in accordance with the 
preestablished rules. In this way, the users are not 
technically forced to verify all parts of their 
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transactions. However, not verifying their 
transactions in full would violate the contract between 
the users and the cryptographic system and would 
thereby absolve all other parties to the cryptographic 
5 systea, for example a sponsor whose employee acted 

without authority, from liability. The non-verifying 
recipient would then bear all the risks of such an 
unverified transaction himself. Furthermore, because 
the root key of the system authority is considered a 

10 trade secret, no one who has not signed the system 

rules agreement may possess a copy of it, and no one 
could claim to have verified any part of the 
transaction. This would make it far more difficult for 
the ** outside** verifier to claim that he had incurred a 

15 loss by ''reasonably relying** on the transaction, even 
if it was in fact valid. This art of keeping the 
system root key as a trade secret lends particular 
force and effectiveness to all the restriction and 
authorization methods described herein. It is believed 

20 that the possibility of incurring the potentially-large 
liability for valuable transactions will persuade users 
to employ the methods of attribute verification of this 
invention. 

25 Restrict ions on Certificate Distribution 

Users and organisations must be able to restrict 
the distribution of all tyi>es of certificates for a 
nximber of reasons. First, the certificates often 
contain confidential business information that the user 

30 or organization prefers not be shared with others and 
that is nevertheless being shared with the verifier 
through the certificate, albeit only for the limited 
purpose of signature verification. Also, users' basic 
privacy rights may be violated if their public keys and 
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net%rork addresses are published. For exasiple, they may 

flooded vith unsolicited business proposals and 
advertisements once their {mblic key^ are disseminated. 
Furthermore, the organization may have a general policy 
5 against giving out ximer identification nuad^ers and 
imblic keys, because they may be used as starting 
^ints for various types of security attacks. 

imis functionality may be is^leo^nted as an 
attribute in user's certificate. If the "distrikmtion- 

10 restriction" attriteate is "OSdiS, the user/ issuer grants 
f^rmission to use the certificate (^ich could be an 
auth^ity or a public key rartificate) only for * 
si^^ture verification; distribution or twctimr 
publication is pr^iibit^* other ^mys to specify this 

15 rwtr lotion might incltule placing the attriteite in the 
organiaation's certif ioeite, inablishing the restriction 
as part of the imiustry-specif ic policy, or (in a true -^c 
X.SOO inqplementation) iwing the X.500 access control 
list Mchanism to restrict access to the Mrtificate. 

20 Although scmB existing general legal basis for 
enforcing this rMtriction might be fmmd under 
c^yright law, that is, if the certificate is declared 
as an unpiblish^ work for which a license is granted 
only to the named verifier, a finrar legal t»sis will 

25 still be ctesirable. 

sg^ar^eag^ ^MuJ rwrtftntfi 

^iMre are seme additional requireMnts on 
smartrards when uswl with commercial digital signature 
30 systiuis. 

ThB first r«^ir^ment is ^ivate key confinement 
and self-certif icatiMfi. Wiat is, the user's private 
si^ature key nmst never allowed to leave the smart 
card. Only in this way can it be assured that theft of 
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the key cannot: be accomplished through purely 
electronic means without leaving any evidence* This 
principle of private key confinement is vital to the 
concept of non-repudiation. 
5 Thus, as illustrated in FIGURE 13, when providing 

a public key 1303 to be certified, the card 1301 must 
attest that the card 1301 is tamperproof and possesses 
a key confining design. Proof can be provided via a 
**device certificate** 1302 stating that the card 

10 originates from the specific manufacturer or product 

line. The ptiblic key 1308 of the device 1301 must then 
be certified by the manufacturer or by a CA designated 
by the manufacturer. One likely approach to creating 
this device certificate would be to generate the device 

15 key pair during fabrication of the smartcard so that 

the corresponding device certificate 1302 could also be 
included on the card. The device certificate 1302 
certifies the properties 1304 of the card, and the card 
generates a key pair 1303,1309 which is to be used by 

20 the user of the card and which the user can have 

certified as his own by any appropriate desired CA. 
Then, when submitting a newly generated public key 1303 
for certification, the device private signature key 
1305 would be used to countersign 1306 the certificate 

25 request data 1307, which is already signed by the 

*newly*generated user private key 1309. 

Also, in a case in which the government requires 
that all decryption keys be escrowed, the card should 
be able to certify that it is incapable of decryption. 

30 This **signature only** certification can be implemented 
through the same mechanisms described above, thus 
allowing the user's signature key to remain exempt from 
escrow reqpiirements. Because it is doubtful whether an 
escrowed key retains any value for non-repudiation 
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services, ^is certification is vital in order to 
prevent the signature key's disclosure through possible 
mishandli?^ during an escrov process. 

S^mrtcards should also be required to guard 
5 a^inst uiMuthorized use of personal identification 
nwBi»r& (PINS) • Konoally, a maartcard is protected 
againat ui^uthorized use by a PIM, the equivalent of a 
SNftssiiord. Typically r a PZM is chargeable only by the 
vm&c ^nA must be a specified length, but typically 

10 nothing prevents the user from setting the PZH to a 
trivial Timber, for ex^i^le all I's or 12 12 12. 
aom^^ard vemiors should be requested to isqplement PIN- 
oh^^i#e routines that insure non**trivial PZKs without 
repeating digits or obvious patterns. Making the PIN 

15 relatively long (at least 6 digits) and nm-trivlal 
reAiMS t^e chance that the card can be operate by 
scmemie finding or stealing it. Suj^mrt for a 6-digit 
PIN requirement can be fmmd in **X9.26: Financial 
Institution Slgn-^On Authentication for Hholesale 

20 Financial Transactions**, ANSI, 1990, vhlc^ is vell-^ 
knom In the art ar^ is ^reJby lncMriM>rated by 
ref«rmce and irtilch Mts forth the ■*oiM*^ln-a-allllon'' 
standard that stetes that a log* In siMiianlmB may be 
e^Mldered secnure If, wong other things, an attacker 

25 has no more t^n a one*ln«a*>mllllon chance of guessing 
tlw correct password and if the system takes evaelve 
acftloii to prevent repeated guessing. Furthermore, 
smarteards should be required to take **evaslve action**, 
for e^^qple, shutting down for a period of tla^ or even 

30 erasing private keys, if too many Incorrect PINs are 
entered by an unauthoris^ user. 

It could also be nMde a requirement that smartcard 
manufacturers use biometrics as more secure methods of 
identification. Extensive work is currently being done 
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in the areas of voiceprint and fingerprint 
identification, as a supplement to PZNs. Hovever, 
while the rates of false positive and negative still 
must be reduced, the main problem lies in securing the 
5 biometric input device and its data channel so that 

they are immune to capture and replay of the biometric 
data* This is not a problem when the biometric device 
is embedded in a concrete wall, for example in an ATH 
or door access system, but it remains a serious problem 
10 in typical commercial office settings. Ideally, the 
card and biometric input device will each be 
tamperproof cryptographic modules that can certify 
themselves and establish secure channels with each 
other. 

IS Smartcards should also be able to maintain an 

**audit trail, or an internal log of recent actions, 
containing at a minimum, a timestamp, transaction 
amount, type code and message digest. This information 
can be compressed into 40 or so bytes so that a 400«* 

20 record circular log would consume around 16K bytes. 

This log would be uploaded and checked only on receipt 
of a signed request from the card issuer over a secure 
channel. Also, the card would not delete the old log 
xantil it received a signed confirmation from the issuer 

25 stating that the uploaded log had been received intact. 
This control mechanism will deter forgery, reduce the 
damage that can be caused by a forger, and allow 
unauthorized or questioned transactions to be 
investigated more quickly and easily. Since most or 

30 all transactions occur off-line from the issuer, the 
card is the best witness of its own actions. 
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c^^Qllltiq Access to the Public of the Root 

Cert:4#viiiia AmfehM-itv Gest Reg^w^rv 

As s^mm in FIGORS 3, iia a particular 

crypt^raphic system, there may be a hierarchy of 

5 certifying authorities (31*33) issuing certificates 34, 

35. In a larger system the number of certifying 

authorities and th^ depth of the hierarchy irauld be 

mue^ grMter. In the structure shewn in FIGURE 3 the 

<»rtifying authority A (31) is the root certifying 

10 authority, vith all other certifying authoriti^ being 
belov it. As noted in the description of WimmE 3, the 
l^iblic key of certifying authority A is wbII- lowvn. In 
a mg^bmA irtiere oertifying aut^rity A a<K»^ts liability 
for ^mf trumactions in ^e system bas^ on infon^tion 

15 in MTtificates issued by A, it traiild be useful ai^ 
dMirable for certifyit^ authority A (tte rtwt 
certifying au^u>rity) to ccmtrol access to its pid>lic 
key. By doing so, certifying authority A could enforce 
rulM on the system vhich vmild ensure thm well-being 

20 of the structure of the syst«B. Various methods for 
oc^ftrolling access to the public key of a certifying 
autiMTity are mam tescrited. 

With ref«rei^e to PKHms 14, in a crypto^aphic 
^elMSi, a c^srtifying austerity (GA) 1402 issues uMr 

25 idtaiitity o^^ificatra 1404 to iwers (fmr eamople, user 
1438 f of ttM raryptographic syston. Certify itig 
Mi^mrity 1402 has a {private key 1406 ai^ a ^blic key 
1408. fhe inriirate key 1406 is used to digitally sign 
the certificates 1404 vith certifying authority's 

30 digital signature 1410. Certifyiiag authority 1402 may 
be any c^rtifyii^ authority in a hierarchy of 
certifying authorities, such as, for example, that 
shoim in FiaiOitE 3. 

Certifyir^ authority 1402 determines inforiMttion 

35 about users of the system, and, based on that 
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information, issues the certificates 1404 to those 
users. A certificate 1404 issued by certifying 
authority 1402 to a user 1438 contains user information 
1410 including the user's public key 1412 and 
5 certifying authority's policy information 1414 

regarding that user. In order for the information 
contained in the certificates 1404 to be verified by 
other users of the system, these other users must have 
access to the public key 1408 of the certifying 

10 authority 1402. 

Effectively, certificates 1404 issued by 
certifying authorities are used by users of the system 
to identify themselves to other users of the system so 
as t.o facilitate transactions within the system. A 

15 recipient (a system user) receiving a transaction 1440 
from another system user 1438, where the teansaction is 
accompanied by a certificate 1404 issued by certifying 
authority 1402 can rely on information in the 
certificate 1404, essentially because the certifying 

20 authority 1402 which issued the certificate 1404 

vouches for ^e information in the certificate and 
accepts liability for certain transactions which rely 
on information in the certificate. If the certificate 
1404 includes policy information 1414 of the certifying 

25 authority, this liability is only accepted by the 

'certifying authority 1402 if the recipient had a valid 
copy of the certifying authority's public key 1406 and 
if the recipient followed the policy 1414 described in 
the certificate 1404. 

30 Thus, for example, suppose that after verifying to 

its satisfaction the identity of user A (1438) , 
certifying authority 1402 issued a certificate 1404 to 
user A (1438) • The certificate includes the public key 
1416 of user A (1438), a policy 1414 of certifying 
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autJiori^y 1402 vith respect to user A and is digitally 
signed by certifying authority 1402. St^>pose, for 
exaiEqple, tbat the policy 1414 in the certificate 
specified that user A can only enter into transactions 
5 on weekdays fron nine in the morning to fiv^ in the 

afternoon. A recipient 1424 of a transaction 1440 by 
user A 1438 and the certificate 1404, can perfona the 
trwmiction vith the knowledge that certifyix^ 
authority 1402 trould acc^t liability for tlw 

10 trat^^Mticm if (a) tl» recipient verified the {mlicy 
1414 for the transaction, that is, if the recipient 
verifi^ that the transaction is taking place vithin 
the alloirad tisie bovo^^, and (b) the r^ipie^t had a 
valid c^y of ttm inablic key 1408 ot the certifyiiig 

15 autbdrity 1402. In other wor^s, if the recipient does 
mt ^leck the transaction vith respect to lAe policy 
then the transaction is invalid. Further, even if a 
recipient checks the transaction frcm user A and the 
tru^MCtion is allo^^ed by the policy of the certifying 

20 authority vith respect to i»er A (as specifiml in the 
certificate) , the certifying authority 1402 is not 
liable for tte ^ansacti<m if tim recipient vas not in 
possession of a valid copy of the certifying 
authority's pi;yblic key 1408« 

25 2&e cryptographic s^tem also includM various 

^^wors 1418 frtio also issue certificates to xmeatB. 

i90twor«*issued certificates are also knovn as 
authorization certificates 1420* 'niese certificates 
1420 function, inter alia, to ep^ify the rules or 

30 policies 1422 of the sponsor issuing them, ^lese 

authorization certificates 1420 can be separate ami 
different fro^ the identity certificates 1404 iMued by 
the ^rtifying authorities (even though the identity 
certificates may contain policy requirements of the 
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certifying authorities) • A user may have only one 
identity certificate 1404 issued by a certifying 
authority 1402. However, a user may have numerous 
authorisation certificates 1420 issued by one or more 
5 sponsors 1418. 

When a recipient receives a transaction from 
another user of the system, the recipient should also 
verify all sponsor policies included in authorization 
certificates included with the transaction from that 

10 user. Thus, in this cryptographic system, users are 
required to enforce the rules (policies) of the 
certifying authorities and sponsors in the system. 

As noted above, in order for the information 
contained in the various certificates to be verified by 

15 users of the system, these users must have access to 

the public key 1408 of the certifying authority 1402 or 
sponsor 1418 that issued the various certificates. In 
order to enforce the rules of each certifying authority 
and sponsor in the system it is necessary to limit the 

20 access to the public key 1408 of some of the certifying 
authorities. In particular, it is necessary to limit 
access to the public key of the topmost (root) 
certifying authority 1402. 

Accordingly, the root certifying authority 1402 

25 keeps its public key a trade secret, and in order to 

obtain the public key of the root certifying authority 
1402, a user (potential recipient) 1424 wishing to 
undertake transactions in the system must obtain the 
certifying authority rules 1426 issued by the root 

30 certifying authority. Recipient 1424 must hash these 
rules to form hashed rules 1428 which it must then 
digitally sign to produce a signed copy of the hashed 
rules 1430. This digitally signed copy of the hashed 
rules must be returned to the root certifying authority 
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1402. By these actions, the recipient 1424 agretes to 
abide by the rules of the certifying authority 1402 
which it has just signed. The root certifying 
authority 1402 may also require that the recipient 1424 
5 also abtain, sign and return rules from other 

certifying authorities in the system as veil as from 
^oi%sors in the systra* For example, recipient 1424 
may aleo be required to obtain sponsor rules 1432 from 
sponsor 1418 and return a signed copy of these rules 

10 1434 to the sponsor 1418. 

Once the root certifying authority 1402 is 
satisfied that it has received a valid «3f^ of the 
system rules si^ed by the recipient 1424, the root 
certifying authority issues its imhlic key 1408 to the 

15 recipi«it 1424. 

Thm root certifying authority public key 1424 may 
issued to a recipient in a niui^r of ways. In 
preferred emtKKliments the recipient is provited with a 
SMure device 1436, for example, a smartcard. In one 

20 referred embodiment the certifying authority public 

key 1408 is imii»diately available in the secure device, 
so that once the recipimt 1424 c^tains the device, he 
has the root certifying authority public key 1408. In 
another preferred embodiment, the certifyit^ authority 

25 public key 1408 is in the device 143« in a disabled 
form7 and the root certifying authority 1402 enables 
the koy 1408 in the device upon receipt and 
verification of the signed rules 1430. 

In some cases it is useful for the root certifying 

30 authority public key 1406 in device 1436 to e^ire or 

to become inaccessible after a certain tiM period. In 
these cases, in order for the root certifying authority 
to reactivate the key 1406, the recipient 1424 must 
again obtain, sign and return the rules of the root 
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certifying authority 1402. These rules may be 
different from the rules previously signed. 

Different certifying authorities, including the 
root, may also require that other conditions be met by 
5 potential recipients before they are given access to 
the public keys of those certifying authorities* 
However, Included in the system rules is an agreement 
by anyone signing the rules to keep them a secret. 

10 cost Recovery 

The rules can also include agreement to pay for 
use of the system. Thus, when a user obtains a valid 
key (by agreeing to follow the rules of the root CA of 
the system) , these rules can enforce agreement to 

15 comply with the payment scheme of the system. 

A cryptographic system can link the operation of 
the system with associated payment by users of the 
system for the transactions they perform and accept. 
The payment for a transaction is made, for example, in 

20 the form of a pre-paid account, an agreement to be 

billed, or a contemporaneous payment of digital cash to 
various parties in the system. For example, a 
particular operations such as digitally signing a 
transaction may cost a user a certain amount to be paid 

25 to the certifying authority which issued the 

* certificate which guarantees that user's identity* 

Some digital payment fxinctions can be built into 
the devices containing the public keys. Since user's 
private keys are typically kept in secure devices (for 

30 example, smartcards) , the secure devices can be used to 
maintain a current digital balance for each user. This 
digital balance can be a debit or a credit amount. 
Every time a user digitally signs a transaction using 
his secure device, a certain amount is deducted from 
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that user's digital balance. If the secure device is a 
debit device, then when the user's digital balance 
reaches sero the device vould become disabled and no 
lon^r able to sign for the user. The user would then 
5 have to obtain further digital credit frcm a certifying 
atithority or some other sensor in the system. If, on 
the other hand, the secure device is a cr^it device, 
then the user might be required to perform a payment 
transaction to the certifying authority at certain 

10 regular intervals, for example, daily, weekly or 

mon^ly* Since the digital credit aunount is available 
from the secure device, the certifying authority could 
foe ensured that the transaction is for the corr ect 
amcmtt. A user who does not perform the required 

15 paymnt transaction would be listed in a CRL as being 
sxxspended or revoked and would no longer be able to 
perform transactions in the system. 

Digital payment on a per transaction basis is also 
achieved using a confirm-to transaction. The user's 

20 authorization certificate would list the confirm-to 

address of the payee. Once the trahsaction occurs the 
payM is notified and can deduct i»yment from the 
user's account. 

25 Pries Information 

Since a user has agreed to pay fees and royalties 
associated with the system, the user can also be 
provided with flexible pricing and billing information. 
User-specific pricing policies can be iorplemented 

30 using certificates. Certificates issued by siK>nsors 
and certifyii^ authorities can include payment and 
pricing policies for particular users. For example, a 
certificate might include a list of prices for certain 
transactions (including, for example, signing using a 
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particular private key^ verifying using a particular 
public key, or checking the revocation status of a 
particular certificate) , a discount rate for particular 
users, a discount rate for transactions with certain 
5 recipients, and rates for bulk transactions. Some of 
the billing is performed by the secure devices of the 
users whereas other billable events can arise froa 
actions perfomed by recipients of transactions. 

In order to implement certain pricing policies, a 

10 certificate may contain various digital fields. For 
some policies, these fields include a revocation 
service address, a revocation service fee, and a 
transaction confirmation fee. The revocation service 
address is similar to the confirm-to address, but is 

15 used only to confirm the validity of the certificates. 
That is, the revocation service screens for attempted 
transactions based on certificates that have been 
withdrawn. The Revocation Service Fee is the fee 
charged for this service. 

20 Examples of these fields are: 

(a) Private_Key_Signing_Fee ■» $0.50 

(b) Public_Key_Verify_Fee - $0.50 

(c) Revocation_Service_Address » 

rev-check§btec . com 
25 (d) Revocation_Service_Fee = $0*50 

(e) Conf irm_Service_Fee » $0.50 
All fees can be stat{»d as flat fees or as a fee 
per some amount of base transaction amount. For 
exsunple, a fee can be specified as ''So.SO** or as "$0.50 
30 per $1,000 of base transaction amount*** 

Given the above examples, a recipient receiving a 
transaction could send the associated certificates to 
the revocation service address and would be billed at 
the rate specified by the service fee. 
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In order to charge for a confirm-to transaction, a 
certificate can also contain a transaction confirmation 
fM, for ea&euaple. 

Transact ion_Confirmation_Pee =■ 
5 ($0.50 per 

$1000 

transaction 
arount) 

In this case each confirmed transaction would cost 

10 the recipient the a^ropriate fee. 

In SCTie instances a recipient may receive a 
^^Asactiwi ^at is too expensive and i^ich it vo^ld 
tt^erefore reject. Accordingly, a digital field 
indicating p«mission to bill 'the sender, the field 

15 being signed by the sender, is also incliKled. TtiLs 
field could include the sender's account number and 
ottier information including a maximtim acceptable 
billing rate etc* This *'bill«*sender'* field would 
ai^ear as an attribute in the sender's signature block. 

20 

Tntelleetual Pnmertv Licensing 

The rales may also include agreement to pay for 
all intellectual profwrty used by a user* For example, 
a system may offer a user patented transactimm, 

25 services or algorithms, copyri^ted materials, and the 
like. In or4er to a user to obtain a public key that 
)^ild enable acccms to this intellectual property, the 
user miust sign the user rules agreeing to pay for use 
of the property. 

30 For exu^le, in one embodiiMnt, the secure device 

contains many un-activated services (for which payment 
is required) . Each use of one of these services 
r^uires payment in the form, for example, of digital 
cash, either by an internal transaction in the device 
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or by some transaction with another user of the system. 
In order to obtain the device, the user must digitally 
sign a set of rules (using a private key in the device 
and unique to the device and therefore the user) • By 
5 signing these rules, the user agrees to make the 
payments as required. 

Signer Imposed Policies and Rules 

A user of a cryptographic system may have an 

10 identification certificate (issued by a CA) and one or 
more authorization certificates (issued by CAs or 
sponsors of that user).. Each of these certificates has 
policies of the issuing party, and a recipient of a 
transaction including any of these certificates is 

15 expected to verify that the transaction obeys all the 
rules specified in the certificates. It may be the 
case, however, that for a particular transaction, a 
user wishes to have more restrictive rules applied than 
are allowed by the certificates. For example, a user 

20 may be allowed to approve all transactions of $1 

million or less, but may wish to approve a certain 
transaction only if its value is less than $1,000. 
Alternatively, a user may be allowed to approve certain 
transactions alone, but for a specific transaction the 

25 user may wish to require one or more co-signers. In 
"support of this featiire, the cryptographic system of 
the present invention provides users with the ability 
to add user rules, attributes and restrictions to 
transactions. 

30 The user rules cannot permit transactions to be 

approved that would not otherwise be allowed. 
Therefore a recipient must always apply the most 
restrictive rules to every transaction. For example, 
if a user's certificate allows transactions up to 
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$1/000 and the user rules specified tremsaction values 
of up to $1 million, clearly the $l,000 limit should 
apply. rOiis cmn be achle^^d, for exaii^le, l>y the 
recipient ai^lyi^ all o€ the certificate rules first 
5 tton, if the transaction is still valid, allying 

all of the user rules. J^^lying the user rules first 
an^ tton the oartifieate rules will also pr«iuce a 
ce»nmct result, ^^mver, sit^^ bMlean TOmbinations of 
rules and restrictions are su{^ort«3, interleaving the 

10 x^mr imd oartificate rules say i^wtuce an iirw orrec t 
result Lt n^ ireful ly imr formed. 

^^ms IS siwms verif icaticm of a user ^raimaction 
^i^ inclt;^s user<*s\^plied rul^. A i»«r ^anaaction 
1502 includes transaction t^t 1506 Asa«ribing the 

15 transaction to be performed by a recipi«it. The user 
appemte to the transaction text 1506 a set at user- 
sx^plied rulM 1504 vhich ^he user vants verified by 
any r^ipient of the transaction 1502 . Tlwn the user 
digitally si^s the c^i>ination of ttM transaction text 

20 1506 «id the rules 1504 to form the transaction 1502, 
fomimr a user signature IS 10 vhich is a^mnd^ to the 
tramactimi* 

The transaction 1506 is then s^t, alcmg with any 
required flqp<»wor and/or CA certificates, for exaoqple, 

25 vith Ch certificate 1508 and sponsor certificate 1509, 
to a*recipient vho must then verify the transaction. 
To do this, the recipient verifies 1512 ^e iMer's 
signature 1510 tising the xMer's public key 1514 from 
the CA certificate 1508. If the user's si^piature is 

30 accepted, verifieation continues, ottorvise the 
transaction is rejected 1514. If verification 
continues, the recipient verifies 1516 the OA's 
signature 1518 using the CA's public key 1520. If the 
CA's signature is accepted, verification continues 1522 
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with the checking of the rules in all certificates and 
those supplied by the user, including sponsor 
certificate 1509. Otherwise, the transaction is 
rejected 1514. If verification continues, the 
5 recipient verifies 1522 the transaction against the 

rules in the CA certificate 1508, sponsor certificate 
1509 (and in any other certificates associated with 
this transaction) . If any of these rules are not 
satisfied the transaction is rejected 1514, otherwise 

10 verification of the transaction continues with the 
verification of the transaction with respect to the 
user-supplied rules 1504. Only if the transaction 
satisfies the user provided rules 1504 is it accepted 
1526, otherwise it is rejected 1514. 

15 The user-supplied rules 1504 can be any 

combinations of the rules known to the system, 
including, but not limited to co-signature 
requirements, temporal limits, transaction amount 
limits, confirm-to requirements and the like. 

20 In some environments users may create sets of 

rules or default rules for themselves for use with 
particular types of users or transactions. These sets 
of rules or defaults may be automatically attached to 
all transactions from those types of users or . 

25 transactions. For example, a user who is bank manager 
laay determine (from experience) that for all 
transactions by new tellers that she countersigns, she 
is going to apply more restrictive rules than the bank 
requires. She would then store these rules in her 

30 system as a default for those kinds of transactions 
that she signs or countersigns. 

One skilled in the art will appreciate that the 
present invention is typically practiced using 
electronic devices such as digital electronic computers 
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and the like, and that the certificates, transactions, 
messages, signatures and the like are digital 
electronic sisals gcmera^ed by the electronic devices 
and transaitted tetiN^en t^m electrmiic devices. 
5 ^teis, a method for securely using digital 

sigiiatiures in a coomercial cryptograj^ic system is 
provi4ed. One skilled in t&e art will appreciate that 
the present invention can l>e practi^d by other than 
the descril:^ ^lOdodiments, which are presented for 
10 punP^se^ of illustration and not limitation, ai^ tl» 
preset invention is limited only by the claims that 
follow. 
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^ 

vmat is claimed is: 

1. In a cryptographic system wherein a 
certifying authority issues digital certificates 

5 identifying users of said system, said digital 

certificates being digitally signed with a private key 
of said certifying authority to form a digital 
signature and requiring a public key of said certifying 
authority in order to verify said digital signature, 

10 and wherein a user transaction in said cryptographic 
system requires verification by a recipient of said 
user transaction, said verification based on 
information in said digital certificates and requiring 
said public key, a method of controlling access to said 

15 public key comprising the steps of: 

denying access to said public key; 
providing said recipient with at least one message 
containing rules of said system, said rules including 
maintaining secrecy of said public key; 

20 by said recipient, digitally signing said at least 

one doctiment, by which said recipient agrees to said 
rules; and 

in response to said digital signing, permitting 
said, recipient to utilize said public key* 

25 

2. A method as in claim 1 wherein said step of 
providing includes the step of providing said recipient 
with a secure device containing said public key, 
wherein said public key cannot be obtained from said 

30 secure device* 

3. A method of enforcing a security policy in a 
cryptographic system, said policy requiring controlling 



wo 96m993 



access to a public key, said method comprising the 
steps of: 

denying access to said public key; 
providing a recipient with a message containing 
5 rules of said cryptographic system, said rules 

including maintaining secrecy of said public key; 

by said recipient, digitally signing said 
documwit, by which said recipient agrees to said rules; 
in response to said digitally signing, permitting 
10 said recipient to utilize public key. 

4. A iMthod of enforcing a security policy in a 
cryptographic system, said policy requiring controlling 
access to a public key, said method comprising the 

15 steps of: 

^oviding a recipient with a document containing 
rules of said system and with a secure device 
containing an inactive form of said public key, %^erein 
said public key cannot be obtained from said device; 

20 by said recipient, digitally signing said 

document; 

in response to said digital signing, activating 
said public key in said secure device. 

25 5. A method of enforcing a sectirity policy in a 

cryptographic system, said policy requiring Controlling 
acceas to a public key of a certifying authority, said 
method cosqprising the steps of; 

by said certifying authority, 
30 providing a user with a message containing 

rules of said system and with a secure device 
containing an inactive form of said public key, 
wherein said public key cannot be obtained from 
said device; 
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by said user, 

indicating an intent to follow said rules, 
said indicating including the steps of: 

hashing said message to obtain a hashed 

5 document ; 

digitally signing said hashed document to ^ 
form a digital agreement; and 

returning said digital agreement to said 
certifying authority; 
10 in response to said indicating by said user, 

by said certifying authority, activating said 
public key in said secure device. 

6. A method as in any one of claims 1*5 wherein 
15 each user of the system has a private key, and wherein 

said rules include at least one of rules requiring 
payment to a third party upon: 

each use of said public key; 

each use of a user's private key; 
20 each certification of a certificate's status; and 

each confirm^to transaction by a user. 

7. A method as in any one of claims 1«*5 wherein 
said rules include rules to pay for use by said 

25 recipient of intellectual property used in creating or 
* operating the system. 

8. A method as in claim 1 wherein said user 
transaction is invalid until said step of digital 

30 signing is performed. 



9« A method as in claim 1 further comprising the 
steps of: 
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in re^>onse to said signing by said recipient, 
said certifying authority accepting a transaction from 
said recipient, said transaction based on said user 
traimaction. 

5 

10. In a cryptographic system wherein a 
certifying authority iseues digital certificates 
id^tifying users of said system, said digital 
Mrtificates being digitally signed vith a private key 

10 of said certifying authority to form a digital 

signature and requiring a public key of said certifying 
authority in order to verify said digital signature, 
and vherein a user tran^ction in said cryptogenic 
system requires verification by a recipient of said 

15 user transaction, said verification based on 

information in said digital certificates and requiring 
said public key, a metlrad of controlling access to said 
imblic key ^mprisLng the steps of: 

providing said recipient vith a secure device 

20 containing an inactive form of said public key, lAierein 
said public key cannot be obtained from said secure 
device; 

in response to a predetermined transaction vith 
said secure itevice, activating said inactive public key 

25 is mid sMure device, said predetermined transaction 
including information from the secure device 
idmtifying cqperational capabilities of the sectire 
device and uniquely identifying said sectire device and 
further including information uniquely binding said 

30 recipient to said prculetermined transaction. 



11. In a cryptographic system i^erein a 
certifying authority issues digital certificates 
identifying users of said system, said digital 
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certificates being digitally signed with a private key 
of said certifying authority to form a digital 
signature and requiring a public key of said certifying 
authority in order to verify said digital signature, 
and wherein a user transaction in said cryptographic 
system requires verification by a recipient of said 
user transaction, said verification based on 
information in said digital certificates and requiring 
said piibllc key, a method of controlling access to said 
public key comprising the steps of : 

providing said recipient with a secure device; 
in response to a predetermined transaction with 
said secure device, transferring said public key to 
said secure device, said predetermined transaction 
including information from the secure device 
Identifying operational capabilities of the secure 
device and uniquely identifying said secure device and 
further Including information uniquely binding said 
recipient to said predetermined transaction, wherein 
0 said public key cannot be obtained from said secxire 
device * 

12. A method as in one of claims 10 and 11 
wherein said public key in said secure device becomes 
5 inactive after a predetermined time period, said method 
* further comprising the steps of: 

after said public key in said device becomes 
inactive, 

in response to another predetermined transaction 
0 with said secure device, activating said inactive 
public key is said secure device, said other 
predetermined transaction including information from 
the secure device identifying operational capabilities 
of the secure device and further including Information 
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uniiiuely binding said recipient to said other 
predetermined transaction. 



13* A method of enforcing a policy in a 
5 cryptographic communication system coo^rising the steps 
of: 

forming a digital message by a user; 
CCTibinir^r with said message at least one user 

rule; 

10 forming a digital user signature based on said 

digital message, said at least one iMer rule and a 
private key of said user; 

combining said digital message, said at least one 
user rule and said digital user signature to form a 
15 digital user transaction; and 

combining with said digital user transaction a 
digital identifying certificate issued by a certifying 
authority, said identifying certificate having a 
plurality of digital fields, at least one of said 
20 fields identifying said user, wherein 

said at leMt one user rule specifying conditions 
\inder which Mid digital message transaction is valid. 

14* A s»thod as in claim 13, fiirther comprising 
25 the step of: 

^combining with said digital transaction a digital 
authorisii^ certificate, s^arate fr<nft said identifying 
certificate and issued by a sponsor of said user for 
authorizing transactions by said user. 

30 

15. A method of enforcing a policy in a 
cryptographic communication system conq^rising the steps 
of: 
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receiving a digital user transaction including a 
digital message, at least one user rule specifying 
conditions under which said transaction is valid and a 
digital user signature based on said digital message, 
5 said at least one user rule and on a private key of a 

user; 

receiving a digital identifying certificate issued 
by a certifying authority and having a plurality of 
digital fields, at least one of said fields identifying 
10 said user; 

verifying said transaction based on information in 
said certificate and in said at least one user rule; 
and 

accepting said transaction based on said outcome 
15 of said verifying. 

16. A method as in claim 15, further comprising 
the step of: 

receiving a digital authorizing certificate, 
20 separate from said identifying certificate and issued 
by a sponsor of said user and authorizing transactions 
by said user; and wherein said step of verifying 
includes the step of: 

verifying said transaction based on information in 
25 said authorizing certificate. 

17. A method as in any one of claims 13*16 
wherein said at least one user rule includes at least 
one of: 

(a) allowed document types of said transaction; 

(b) allowed locations at which transactions can 
be formed; 

(c) allowed times at which transactions may be 
formed; 
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(d) a time period within which said signature is 
valid; 

(e) a monetary limit for said transaction; and 

(f) consigner requirements for said transaction. 
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